Consider this approach for a moment in the light of the concept of technical debt.  Increased features and new products mean more maintenance costs.  Increased speed to market means increased bugs.  Rising technical debt means that your team will be able to contribute even less in the mid-term and long run.  Contributing new, buggy things rather than increasing the value of what you have simply lowers your perceived value to the business.

Before deciding to add new projects, products or features, ask yourself this:  is it time instead to pay down existing technical debt?  What can I do to lower support costs?  How much better can I make what I have?  Do I have any open requests from the business to solve old problems?  Can I increase my perceived value by simply focusing on lowering overhead and getting rid of ‘old’ problems that have been lingering?  Turning your efforts inward to improve now will give you a stronger position in the mid-term and long-term.  You will have lower maintenance later when you ramp up new projects, and by clearing your backlog, you’ll be surprised at how much support you will garner from your business partners.

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.

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.

1. The company needs more manpower or expertise in some area
2. They have a brilliant idea:  Hire consultants!
3. Consultants come in to help.  Since the company either hasn’t the manpower or expertise to do the project, they hand the consultants what they know and have, which isn’t much.
4. Consultants start trying to do the job right (you hope).  They hold meetings, ask questions, gather requirements, start work…
5. Company loses patience.  Needs product quickly, doesn’t want to spend money.
6. Consultants give up on being allowed to do this right.  They hurry.  Requirements gathering sometimes suffers; writing documentation reduces drastically.
7. Consultants hit company’s deadline (if you’re lucky).  Company asks consultants to turn over documentation and do a knowledge transfer to internal staff.  Company gives consultants a meeting (usually a couple of hours) to transfer everything the company’s needs to know about multi-month project to poor guy who may never have even heard of the consultant’s project.
8. Consultant does so and leaves.  Company struggles to maintain what the consultant has done.  Company swears never to hire consultants again.
9. Six months later, more consultants are engaged to redo what the last consultants did.

Sound familiar?  Some of this may sound extreme (or maybe not extreme enough, depending on your experience).  It happens all the time though.  Consultants are a double-edged sword.

A double-edged sword, though, in the right hands, is a very powerful weapon.  So how do you transition from an accident waiting to happen to a grand swordmaster?

The secret, as with most things in life, is practice and discipline.  Here’s tips for succeeding with Consultants:

Plan ahead:  You should have a plan in place as to what activities you believe the consultants need to do when they arrive and for the early period of the engagement at least.  You should go over this plan with the consultants beforehand and gain buy-in, adjust as needed, etc.  Frankly, if you don’t know what you’re going to do with them before they arrive, you shouldn’t be bringing them in yet.

Share Expectations:  First thing when you bring consultants in, give them a quantifiable, measurable explanation of what you need and what you expect of them.  Leave as few things vague as possible.  This will save time on both sides, as it should answer a lot of their questions, and if they weren’t going to ask questions, it will save you the pain of any incorrect assumptions they might have made.

Set the Standard:  Create a system of standards for the type of work the consultants will be doing- coding standards, database standards, data analysis standards, business analysis standards, etc.  You should already have these in place for your existing staff (and if not, you should really be correcting that).  Give these standards to the consultants when they come in-house as part of your expectations.  Just tell them up front:  “This is the way we do things here.  Consistency is important to us, as it helps us manage things long-term.  We appreciate any improvements you can suggest and will consider adding them to our standards, but we do expect you to follow the standards.”  Your people really will appreciate the consistency later, as it will help make the consultant’s work more familiar right away.

Review, Review, Review:  Conduct very regular reviews- code reviews, if they’re developers, document reviews, whatever is appropriate to the work at hand.  It may seem tedious, but a one hour review every week will help save you weeks of work later.  It will help keep the consultant on track with your expectations, assure they do stay within your standards, and the reviews will help you have a better grasp of what they’ve done later.

Feedback is everything:  Don’t review to grade.  Review to provide feedback.  Your consultants want to do the right work.  Regular checking in and providing constructive feedback will help them go in the right direction- and again, it will help you be more familiar with what they’ve done later, when you have to maintain it yourself.

Participation is encouraged:  Some people don’t like consultants to spend too much time chatting with the existing staff, coming to meetings, etc.  After all, they’re (usually) paid by the hour.  The more you can involve the consultants with your culture, though, and let them participate in informal sharing of information, the more they will learn to help them produce better products for you.  The information that they share in turn will help your staff better maintain their work after they’re gone as well.  There’s also countless little things that your staff can learn from the consultant- a quick infusion of new “tricks of the trade” is always good for the shop.

Do you have other useful tips for managing consultants?  Drop them in the comments!

As a project manager, you fundamentally have only four resources to manage:  Time, Money, People, and Quality.  Meetings take up both time and money in the form of man-hours, and they also take people off-task to communicate.  In the process they can either build or harm morale.

Wait, did I say four resources?  Project management is a holy trinity!  Why did I put in the fourth?!?  Because people’s attitudes, motivation, and morale are a hidden variable that can stretch the other three resource types, or they can waste them.  It is therefore arguably the most important thing you can manage.

Useful meetings bolster morale.  They give people what information they need, allow them a voice and participation, and make them feel valued.  Non-useful meetings make people sit through other people’s conversations, don’t allow them to participate, fail to communicate information of value to all of the parties involved, and make you look like you’re wasting people’s time.  As a time waster, you lose credibility, damage people’s morale, and lower your value and the value of your project in people’s eyes.

So if meetings are so important, how do you know when and how to hold ‘good’ meetings?  Here’s a general checklist:

• A working meeting, where people are going to participate and make decisions of value, can be no larger than 5-7 people as a general rule.  Three to five people who contribute value is the ideal amount.  Any more than that, and there’s too many ideas at once.  Things will fall into rhetoric, and you will lose more ground than you gain.
• A meeting to present information and ideas can be as large as needed.  These are generally known/held as presentations.  You should follow good presentation guidelines, of course, such as encouraging questions, keeping good flow, keeping the group on task, etc.  If decisions come up to be made, make note, but get the decision-makers together in a sidebar or another meeting.  Don’t waste everyone else’s time making them sit through the decision-making process unless you think that understanding the discussion behind the decision has real value.
• Project status meetings should never be more than 30 minutes.  Ever.  They should cover a status report that has already been distributed.  They should briefly cover the report contents, make sure that the report is correct, that everyone understands it, and to check to see if there’s new action items.  No more, no less.
• The above-mentioned status report should be written from one-on-one or small group meetings.  Get the right one, two, or however many people are needed to cover a small and related section of the report together and hold brief talks to update.  If the update is simple enough, a phone call or an email will do.  On average, I get invited to at least one meeting per week that could have existed as an email.  Don’t do this to people.
• If the meeting doesn’t have value to someone, don’t invite them.  If you need information from them for the meeting, go get the info beforehand. 
• As a corollary to the above rule:  If in the process of getting that information you learn that they do think the meeting has value, invite them.  That person wants to be involved- don’t shun their interest.
• Whenever possible, talk to decision-makers before a big decision-meeting.  Get consensus and share information where possible and take the temperature of who wants what.  If you can get the decision made or close to made before the formal meeting, you will save a lot of time, present a more united leadership front, and gain confidence and morale within the team.

These are just a few important things to think about when handling meetings.  A meeting is a potentially powerful way to communicate- after all, you have everyone together in one place.  At the same time, you are spending resources.  Count up the salaries in the room and you’ll see.  Make sure those resources count!

Why is this? Simply put, if you will settle for substandard people to work with directly, you will settle for their substandard people too. They will do this for several reasons:

1)If the project doesn’t go well, it’s just as likely to be blamed on your substandard people as theirs.
2) If you feel the project is important, you will assign good people to it. If you didn’t, obviously the quality of the project isn’t a priority to you, so they should save their good people for projects you feel are important.

The bottom line: Involve your good people with your important projects, even if you are outsourcing them. Always keep good people involved with interfacing with contractors, consultants, and outside people. Even if you are using your poorer people on the project, keep the best people on the interfaces to help get you quality people for your projects.

Most organizations hire full-time employees based on full-time work. That is, if you can prove that there is a constant 40 hours a week of work for a given position, you may have the position. If the work is temporary, i.e. project-based and will end when a project ends, it’s much harder to hire. You know at some point the project will be over, and when it is, you will not (in theory) have work for that person.

If your company validates positions in this way, you should consider the basis of the work that your company or department does. Is it primarily project-based, or is it more standardized? If your IT department is like most IT shops, for example, you have some people who are responsible for continuous tasks- supporting applications, for example, or systems administration, and you have some people who are responsible for completely project-based work. The project-based people are constantly executing one project after another. The work they do on a project ends in time, so they are temporary, yet at the end of that project there is always another project. You also probably have some people who do a percentage of each- some routine work, some project-based.

If this is the case, you should be careful to examine how you are justifying time when you hire people. If the nature of what the position does will consist of 50% project-based work, include that. Fight HR and anyone else you have to in order to stick to this, but do so. If you hire all your people to fulfill tasks that must be done, then you will always be overrun when the temporary, project-based work comes around. Resources will always be too tight. Project deadlines will always be threatened. Management will become a group of competitors jockeying for resources to finish their projects instead of working together as a team. You will create overworked labor that resents their bosses and their conflicting priorities, a management team that competes with each other to get what they need to do their jobs rather than helping each other, and an executive team that looks inept from the ‘trench’ view because they have failed to plan labor right and appear to demand the impossible from their employees without providing enough resources to accomplish things. Your company is a team competing with other companies- don’t let your hiring processes reduce it to competing with itself.

While pondering this, I’ve run across a few articles that summarize things very well:

On identifying a great programmer:

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

On recognizing, hiring and keeping a great programmer:

http://outofthetriangle.wordpress.com/2008/02/03/hiring-the-best-coders/

On some great theory that can help you understand the type of thinking you’re looking for:

http://outofthetriangle.wordpress.com/2008/01/31/600-line-design/

and last but not least, for those out there who’ve bungled a developer hire in the past:

The 10 Most Serious Hiring Mistakes and How to Fix Them

http://peeyes.spaces.live.com/Blog/cns!9D867CC7936D3E20!716.entry

Here’s an example: a project is dependent on getting a large, complex oracle database set up. The project manager checks with IT and yes, there is an oracle DBA on staff. Yes, the DBA can be available for the project. Yes, the DBA should be available around the target deadline.

Sounds fine, right? What can go wrong here? The project manager neglected to check on a few things, namely:

1) Are there any other projects going on that require an oracle dba? Are any of them higher priority than mine? (Hint: if you’re #3 on the list of oracle dba needers, you should keep a close eye on the other projects and probably talk to the other PMs).

2) Just how many oracle DBAs does IT have? How many of them are actually qualified to do the work you need? (Hint: if they have only one or two, be concerned and include contingencies in your plan)

3) If there’s only one or two DBAs available, talk directly to those DBAs as soon as possible. You need good communication with them from now on. If they are out sick, are planning a two-week vacation, etc, then you need to keep this in the plan.

4) How many production oracle systems does IT have up? Are any of the DBAs IT has offered you responsible for production support? If so, you may be at the mercy of any of these existing systems if they go down, their scheduled maintenance schedules (find out about these!) and change requests for any and all systems that are higher on the company’s priority list than you are. You might even consider checking the bug list for any production systems a lot higher on the priority list than you are, so that you can anticipate if there’s changes coming that may affect your schedule.

Does this example give you a good picture of my point? If you are going to depend on a resource, make sure you check on:

1) The availability of the resource
2) The commitment of the resource
3) The *possible and potential* commitment of the resource
4) The *potential availability* of the resource
5) Where your project falls on the priority list against other potential demands for commitment and availability of the resources your project depends on

To sum it up, there is always a large number of important things going on in any company. Any resource you depend on more than likely is committed to some of these other things. Understand what surprises can come up that can claim your resource, keep up with and plan for these possibilities in your project plans. This will help you build a smarter, more effective timeline.

This is such an obvious-sounding theory that it requires a bit of thought to accept.  After all, if it were that simple to keep your project on track, we all would have found it by now, right?  I went back and did some research in a random sample of old projects though, and it holds true- when people gave me estimates such as “four weeks” and the date slipped, it came in 1-2 weeks late.  When they gave me estimates in days, it slipped by days, not weeks.  And sure enough, in the few cases where there was a mega-task estimated in months, when there was slippage, it wasn’t in days, or weeks, or hours… it was by a month or more.  Rohanna goes on to include in her article her theories as to why this happens, and I have to agree- the bigger the estimation unit used, the less thought that the estimator has given the task.  Someone who says “20 days” has thought more about a task than someone who says “four weeks”, and certainly more than someone who says “one month”.

Consider this when you are doing estimates in your project plans.  More work yes, but when deadlines matter, you can’t afford not to plan enough.