Here’s another aspect of Capital we don’t always think about.  Physical assets that are Capital cost maintenance over time.  If you buy an office building, it requires maintenance.  If you buy a car, it requires maintenance.  The bigger the thing, the more maintenance it requires over its lifetime.  This is just as true with software.

The larger and complex a software project is, the more you may have in the following costs:

• Hardware: servers, desktops, network equipment, etc all cost money, must be maintained, and have to be replaced.
• Hosting: Hosting internally means costs within your data center- more servers, more cooling, more power, more floor space, more people.
• Code: Greater the size and complexity of the software, the higher the likelihood that you will have ongoing bugs that need to be fixed.  Also, you will have real costs attached to updating for security fixes, changes to the Operating System, to your web server, to the database, etc.  Also, some types of systems will require constant updates.  This is particularly true for software that emulates business or legal processes and evaluations.
• Training: Every new piece of software requires documentation and training for your users.  Adding features means revising training and updating documentation.
• Liability: Software stores data and has to handle data correctly.  Security flaws, calculation errors, data mis-entry, and more are all real areas where you (or worse, your clients) can end up with the wrong data in hand and making bad decisions as a result or receiving private data they were not meant to see.

These are all real costs you have to consider when building a new piece of software for your company.  Sure, you may be able to justify the build based on saved labor for the business, but what about when you add additional costs for maintaining it?  Does the cost still balance?

Another point to consider is are you staffed (and can you afford to be staffed) to support the product.  If you had to bring in consultants to build the software because your existing staff doesn’t have the bandwidth to build it, then you should tread carefully here.  Make sure to measure that your existing staff has the bandwidth to support the new product after the consultants are gone.

The biggest reason to consider this, though, is to keep yourself in reality.  Two of the biggest and most common problems in companies today are rising IT costs and shortages in IT resources.  Failure to consider, plan for, and allocate for the amount of work necessary to support IT projects after the project itself is completed is one of the biggest culprits that can be blamed for these problems.  Be sure you think through these post-development costs before you engage in new software development initiatives.

Marketing Interview

Project and Operational teams work like this.  I think we’ve all experienced a “bad apple” on a team.  Dealing with the one person who, for whatever reason, is doing a bad job, invariably seems to drag everyone down.  Your best performers will vary as to why they get worse at what they do- resentment over everyone not pulling their own weight, frustration at obvious incompetence, impatience with poor communication skills… the list goes on and on, but it always happens.  Not only does the poor performer not do well, but they drag down the team.

This is not just random observation, although it’s likely many of us have seen it, but it’s shown up in research.  Here’s an interview from This American Life Of Will Felps.  Felps is a researcher and professor at the Rotterdam School of Management.  His experiments with inserting bad apples into work teams showed that not only did bad apples damage work teams, within 45 minutes other team members would begin to take on the characteristics of the bad apple.  Everyone on the team’s work would degrade.

Another effect of a bad apple is that their presence is often seen as a challenge to your leadership.  Your failure to do something about bad performers reduces both the trust and respect of the rest of your team in you.  I’ve heard this said to me and of my colleagues more than once in my career: “If you/mangement/whoever can’t see that (insert bad apple here) is wrecking this project, you/they are an idiot.  If everyone else can see it, why can’t you/them?  If you can, why don’t you fix it?”  Or, here’s the worst one of all:  ”If you/they don’t care that (bad apple) is wrecking the project, then obviously you don’t care.  Why should I?”

I’m not saying can everyone who does a bad job on something, but the one thing you must do is take action quickly. Correct the behavior if you can; if you can’t, get that person off the team they’re screwing up and get them on to something else- either in your company or not, but get them out of there.  Too many times companies sit on their poor performers.  I myself have been guilty of this before.  The instinct is to give people a fair chance, but ‘fair chance’ does not get the job done.  Action does.  Take action to rehabilitate or remove your bad apples.  Don’t drop the performance of your entire team.

Transparency can be a double-edged sword.  There are aspects of any process that may be par for the course, but to an outsider, look like unmanaged, undisciplined chaos.  Watch any of the “reality show” series like Mythbusters or Junkyard Wars, where people build very complex things very quickly, and you’ll see what I mean.  The team that looks under control sometimes is not, and vice versa.

This is particularly true in software development, where developers often debate the hows of solving a problem until just the right detail shows up; where it’s hard to commit to a final deadline or even an order in which you will do things until the last detail shows up, where what appears to be small detail changes to the outsider can lead to huge changes in the software.  A good friend of mine refers to this process as “making the sausage”.  Most people love sausage; if they saw how it was made or what went into it, they wouldn’t be able to eat it.

So if transparency is so dangerous, why is everyone doing it?  Why shouldn’t we run from it?  Why aren’t projects falling apart all over the business world globally because of it?  The truth is that some are.  Like all tools, before you can use Transparency to its fullest potential, you need to understand what it’s for and what you are trying to do with it.  if you use it incorrectly, it will hinder rather than help.

Transparency lends value in two important ways:  it spreads useful information, and it builds trust between groups.  There are two key words there:  useful information, and trust.  These are actually very easy to apply here if you think about it:  information people do not understand is not useful.  People do not trust things that they do not understand.  Also, in the category of trust, no one trusts anything or anyone that surprises them in a negative way.

Drawing from this, we can apply a set of simple do’s and don’t’s to Transparency to make it work better:

• Do share anything that is a roadblock.  Never let people get surprised when your team runs into trouble.
• Do summarize wherever possible.  Keep things in terms that all teams understand.  Ditch jargon.
• Do be prepared to explain details, especially related to roadblocks.
• Do be prepared to rate the amount of trouble the roadblock really is- people fear the unknown; quantify it where possible.
• Do not share details for the sake of sharing them, unless you’re specifically having some type of true learning session.  Respect people’s limits in how much data that they can take on a time.  If you bury people in information, they’ll miss the important parts you share.  Make sure the most important details are always at the top.
• Do be prepared for that there will be times that too much detail comes out, and you’ll have to handle it.  A lot of people are problem-solvers in the business world.  That’s what we all do.  If you get too much detail in front of them related to a problem, they will want to dig into it.  This is a delicate balance, because often the time you take explaining what’s going on just contributes to delaying the solution and contributes to your frustration.  On the other hand, not explaining enough frustrates the people you are sharing with- and it can make them feel you’re hiding things from them.  This is one of the slippery slopes of Transparency where you can build stronger trust, or you can do a lot of damage.
• Do not make shared decisions in a vacuum unless you have no choice.  Once you open things up, you hurt trust when you start leaving people out.

There’s a lot of other things to consider, but the bottom line is Transparency is about building Trust.  Follow your instincts around building Trust and respecting people’s time.

Something my company has been struggling with for years has been how much detail is enough for project reporting.  This has been even more complicated by the founding of our PMO.  Here’s a few of the issues you run into when the business folks look too deep into the project details:

• Reporting overhead:  the deeper you look, the more effort is put into telling others what’s going on by the managers who are supposed to be spending time getting things done.  If you pull away too much of their time, the project actually starts to fall behind- because you so busy looking at it that you monitor it to death.  At some point, you have to trust the project workers to handle the details that they gloss over in meetings.
• Knowledge transfer overhead:  this goes in part with reporting overhead.  The deeper a detail you look at, the more explanation goes along with it.  This is especially true in the IT world.  Some tasks and problems require a very in-depth technical knowledge to understand.  The deeper you look into them, the more background information and technical detail that has to go along with it.  All of that communication overhead pulls people away from the real work.  They are talking about doing rather than doing.
• Executive attention syndrome:  if the reporting goes deep enough down the rabbit hole on every project, your company’s leaders soon find themselves spending all their time drinking from the information firehose and not enough time actually leading.

You simply cannot manage what you don’t understand, nor can you delegate it or request updates on it.  Understand and manage to results, not to line items on a task list.

A key task in the critical path of your project is completely out of control.  It’s not getting done, what is done is all wrong, and everything is late.  You go and talk to the person who is in charge of it, and you hear those fateful words, “I didn’t know X, Y, and Z about this project.  When was that said?”  You immediately go back to your desk and add that person to every project meeting to ensure it doesn’t happen again.  In your next project, you vow to not leave anyone off any meetings, because lack of communication causes problems.

Sound familiar?  It’s common in project management- and it’s also the wrong reaction.

How much homework do you do on who should be in each meeting of your project?  I’m going to suggest something that may be sacrilege to many folks:  overcommunication through meetings can damage your project.

Think about it:

• By including people in a given meeting who didn’t need to be there, you are wasting company resources and robbing other projects of available resources.
• By including people in a meeting who doesn’t need to be there, you reduce how engaged that they are in your project.  A few meetings like this, and you will completely loose their attention- which means that they’ll miss details later that you can’t afford them to miss.
• Worse, if they perceive your meetings to waste their time, they will stop coming.
• Even worse than that, their manager might pull *all his resources* out of your meetings rather than waste their time.
• People sitting in the meetings not paying attention will naturally set a bad example to others.  If others in the room are not engaged, your other team members will also become less engaged. 

What can you do to avoid these problems?  Simple:  do your homework before you hold a meeting.  If certain people do not need to be there, be sure to leave them out.  If they missed something that they need to hear, DO NOT tell them through sending out a project status report to the whole team- take the time to send them a note directly.  Trust me, your status report suffers from the same attention problem as your meetings.  Sending a direct note will better draw the team member’s attention.

What about operations?  How does this fit in?

The reality of most companies is that they do not have seperate project-based resources versus operations-based resources.  Major operational initiatives and problems can derail your project quickly.  An over-abundance of projects can rob Operations so thoroughly that needed maintenance is ignored, and your operations deteriorate (just ask the american government about this).  Major operational problems clash with major project initiatives.  Huge political battles can ensue, creating inaction as people who need to do do the work in question instead go sit in meetings waiting for a decision on which work to do.  People end up making decisions on an island at times, just picking a direction based on their own personal knowledge rather than wait on the corporate machine to find a direction.

Rather than get lost in these situations, get a grip on your Operations.  Include them in the resource planning process.  Most importantly, include them in your prioritization process.  Is the most important project in the company more important than maintenance of the most important existing product?  What about the fifth most important product?  The fifteenth?  Which customers’ business is more important than your projects?  Customer problems can just as easily steal resources.  Not all of your customers will be more important than the development of your company’s future either.  You have to count them as part of your prioritization process, and you have to make hard decisions like this.

Doing this type of process is hard.  It is also vital to your company’s ability to react quickly and decisively to the unexpected.  You, and more importantly, your team, need to understand and agree on what comes first.