This is a simple concept we learn as kids.  It applies all through life.  It also is an old cliche, and it gets written on time and again.  Nevertheless, I’m going to touch on it here, because it’s so relevent to problems I see so many times in projects.

Goal number one of any project is simple:  Complete the mission.  Do it on time, in scope, and within cost if you can, but if you can’t, the goal remains:  complete the mission.

Your mission is whatever your project scope is.  It is not to complete all the tasks in your project plan.  It is not to be on time with all your tasks regardless of if you’re rushing work to the point that it gets sloppy, that details get missed that may cost the project dearly later on.  Your goal is to complete the mission, and do it well.  Listen to your people when they bring changes to the table for good reasons, whether those changes are good or bad to your project plan.  If you have to adjust the schedule, adjust it and communicate those adjustments to reset expectations with stakeholders.

Keep your eye on the ball.  Complete your mission.

Fear not, however; here are four simple gut-checks you can make to evaluate if a project is worthwhile.  These are not guaranteed to bring you to the most important projects, but they will help you weed out the red herrings.

• What problem does the project solve?

If you can’t name a specific, real, practical business problem either of your own or of your clients that your project solves, then it isn’t valuable.  The problem should be quantifiable, have a quality factor involved, and have a real cost involved with not solving the problem.  Cars solve the problem of how to travel by land quickly over roads.  The internet solves the problem of how to exchange information and data quickly over a global network.  A communications portal so that your CIO can communicate information about his recent vacation does not solve a practical problem.

• Does the project simplify doing business?

Quite simply, if your project complicates things, then people will not embrace it.  Your staff won’t; your clients won’t.  The pros must outweigh the cons, and they must do it in a manner that can easily be discerned by the people involved.  If you can communicate your vision in such a way as to make the benefits clear, this works, but the benefits must be there.  If it makes daily routine harder, people will naturally work around it.  It will not see use.  And that means that your project will not bring value.  No value, no reason to implement.  It’s that simple.

• Is the Resulting Product Going to Be Easy to Use?

The clocks on VCRs all over America blink 12:00 for a good reason.  How to program them is not completely obvious and transparent, the feature is not absolutely necessary to gain enjoyment from the VCR, and therefore people don’t use it.  Likewise, MP3 players were not really all that new of an idea when the iPod hit.  Relatively new, yes, they weren’t the first to market.  They were, however, the first to market that was easy to use.  Why?  iTunes.  iTunes made it easy to purchase new music, to load music onto the iPod, and so on.  Viola, the MP3 revolution was on.  There were lots of sites you could buy music from, just like portable music players; the iPod and iTunes just made it all easy.

If the end results of the project are not easier to use and understand than it is to just keep doing things the old way, adoption will fail.  As we said before, if adoption fails, so fails the project.  It won’t be used, so it’s not really worth implementing.

• Is It Cost-Effective?

This should be an obvious thing, but too many times it’s not.  I have seen project after project done because it is the will of some executive, without the implementors communicating the costs of the project to that executive.  I often wonder how many of those projects would have seen the light of day if the costs had been known?

Any project should be evaluated for the cost of implmentation versus the cost savings involved.  Not all projects that are worth doing are cost-effective; some things are worth more to your company than money (for example:  things that earn customer buy-in, things that bring value and loyalty from your employees, etc.).  Still, no project should be conducted unless you have some idea what the cost is of the value that you are gaining.

As I said before, these will not end-all solutions for evaluating projects.  If a project does not pass these four basic checks, however, you definitely should do a hard evaluation as to why you are pursuing it.

This is where Change Management enters the picture.  We’re all familiar with the premise of Change Management:  identify the change, identify the impact of the change on the project, and get sign-off.  How good of a job are you doing at that second part?

Evaluating impact must weigh several things:

• Effect on the project timeline
• Effect on the project cost
• Effect on other projects in the company

What’s that third one, you say?  Other project in the company?

Unless your company just has available resources sitting around, then yes, every change to your project affects other projects- in both time and money.  The money for your change has to come from somewhere.  So does the labor.  Adding to your project must therefore, reasonably, set back other projects.  Even if you work overtime to make your project happen, you take away capacity of all of the potential overtime that could be used for other projects for things like recovering from falling behind schedule, getting ahead of schedule, or even, you know, even change management.

In a nut shell, all changes to your project not only impact your project, they impact the company as a whole.  Never forget to assess that third step and, if the impact is significant, get executive sign-off.  Don’t forget to include the need for executive signoff on signficant project scope changes in your Change Management plan as well.

1) a reliable web server
2) reliable power for the web server
3) reliable physical location for the web server
4) reliable network connection to the web server
5) failover capability in the event that the web server fails
6) reliable backups in case the server crashes
7) physical colocation of servers in the event that one server site is damaged in a disaster
multiple network connections in the event that a network connection fails
9) personnel who are experts on each individual component of your website (available 24/7)

and so on, and so on…

See what I mean? Unless you have the budget and manpower to support a 99.999% uptime, you are wasting paper if you set that as your SLA goal. In fact, if your business falls too far short of the goal or the goal sounds too unrealistic to your people, then I guarantee that eventually your staff will become pessimistic about it. The uptime will become an unhappy point with them, an inside joke in your company, and it will tarnish the reputation of anyone who was foolish enough to sign off on it.

This line of thinking applies to other goals in your company as well. It is important to think high and stretch your people. Challenges make your people stronger. They make your company better. If you are not stretching your people, you may risk your competitive edge. Setting too unrealistic goals, however, will simply set your people up for failure- and they will remember you for it. Being set up for failure is demotivating.

For that matter, setting too many ’stretch’ goals is just as bad if not worse than setting one unrealistic goal. Your people will get sick of every single win being a struggle to the finish. They will start to whisper things like “Who does he think we are?” and “Sure, just pile on more to the load, I’m stretched too far now anyway!”. Do you want to be thought of that way by the people you lead? Or, to be more specific, do you think your people will follow someone who they think these things of?

Never set goals that you or the people you manage do not have the resources- time, money or otherwise- to reach. Stretching is good for your business. Jumping off cliffs without a parachute is not. Others can see whether or not your goals are reachable given the resources available. Your people may see this as lack of respect for them (”He thinks we’re miracle workers!”), lack of ability to plan (”He doesn’t care how many hours we work!”), or a lack of knowledge (”Doesn’t he know that can’t be done with what we have?”). They will mistake it for incompetence, and your credibility with your people will take a huge hit that your ability to lead them may never recover from.

I love this tool and have used this concept for years.  Not just as a fun tool, but as a very serious tool.  Meetings seem like a way of life in some companies, and you can easily spend tons of time in them, but you always have to ask yourself the cost, especially if you are holding those meetings to solicit information to help you make decisions.

I was once involved with a series of meetings that centered around studying and deciding whether or not to make a business decision that was going to cost our company around $10,000.  That’s not a small investment and worth talking about.  Still, after a few weeks it was out of hand.  We were including too many people and agonizing over the decision too much.  I brought the problem to the attention of my boss (the ultimate decision-maker).  The conversation was something like this:

“Hey, we’re spending a lot of time on this.”

“I know, I need to make a decision, we need to think a bit more about it I think.”

“Well, think fast, you’ve spent $5,000 on this decision already.”

That got his instant attention.  It was a rude jolt, to be sure, but it was a needed one, and well-received.  He asked what I was talking about.  I pointed out the number of hours in meetings, pointed to the average cost per person’s time that we use for pricing project resources for the people in those meetings, did a simple math calculation, and poof.  $5,000, give or take a few hundred.  That ended the meetings right there.  He made the call the next day based on the information he had.

Being cautious and risk-averse is a reasonable approach to doing business, but never be so cautious you overrun your costs just trying to make a decision.  Keep your meeting costs in mind.  Calculate the estimated cost of a meeting BEFORE you call the meeting, then decide if what you’ll be accomplishing in that meeting is worth the cost.

If you are like me, you a) like to know what expectations are, b) what your responsibilities are, and c) if there’s any tasks involve that you just hate doing.  Here’s a quick set of guidelines that you should check on to help you understand what you are getting into with a given job or assignment:

1. Does the project team or any portion of it report to me?
2. Am I responsible for creating, soliciting, documenting or approving requirements?
3. Am I responsible for creating or approving functional specifications?
4. Am I responsible for creating or approving technical specifications?
5. Am I responsible for creating or approving solution design?
6. Am I responsible for creating, contributing, documenting, or managing the project schedule?
7. Am I responsible for tracking or leading the project?
8. How will my responsibilities change over the life of the project?
9. Am I directly or indirectly accountable for the project outcome?
10. Am I responsible for creating, planning, distributing, or delivering training?
11. Am I responsible for creating, planning, or distributing marketing and communications to end consumers related to the deliverables of the project?
12. Am I responsible for creating, planning, tracking, or managing the project budget?

Not only should you find these things out early help you determine what expectations the business will have of you if you take the assignment, it will also help you get a full scope of the project you are getting yourself into.  By asking simple leading questions such as “I’m not?  Who will be responsible for that?”, you quickly find out a lot about how much the project has been thought about, the real resources available to the project, the organization’s level of commitment to the project, and much more.

All of this should be obvious things that every project manager should know about a given project- but surprisingly, I find many times that project managers do not know all the answers to these questions even after having taken a job and managing a project for months.  Do your homework.  Find out the basic responsibilities withing your project assignments.  Your life will be easier.

• Communicating about the project to stakeholders
• Communicating about the project to team members
• Updating your project plan in your project tracking software

Which one of those three do you really think matters to the success of your project?  There’s no question that project tracking software and having an up-to-date project plan is helpful, but it is technically possible to complete an entire project without ever touching it.  You will never succeed without communication, and lots of it.  If you are spending more than 20% of your time on this part of your project, then you’re probably spending too much.  If you’re spending more time on it than this, start examining how you’re using the software and looking for ways to improve your efficiency.  So many times, because project management software is capable of managing so many details for us, we get lost in the details of using it rather than the details of managing the project.  Project management is far more than updating little checkboxes on an electronic checklist.  Get up from your desk, shut off your software, and spend some quality time with your team getting things moving.

Right?

This is a trend I’ve seen in many places.  The project manager fights for their project to a fault.  They get the money and resources they need.  They win the battle of conflicting priorities for shared resources.  They take no prisoners and get things done.  While in the process of doing it, though, sometimes they rob other projects and processes of resources, and that ultimately hurts the company significantly.

As a project manager, you can never lose sight of the fact that you work for the company, not the project.  When there is a scheduling conflict, you have to ask questions and find out what the conflict is and what the importance of the other item is to the company.  There are ultimately times when you should stand down and let the other people through.

Your stakeholders can sometimes make this a delicate balancing act.  They will not always agree that the other project should be let through.  Not everyone thinks in terms of the Company as a whole.  You should take the time to explain yourself, though, and if you find yourself and what you believe is the correct thing to do in conflict with your stakeholders or, worse, project sponsor, take the time to escalate.  Don’t do it in a contrary manner; simply consult the right authority in the company and ask which choice takes priority.  Once you do that, report your findings and acquiesce to it.  Refer to the higher decision and seek help from leadership in explaining things if necessary.

Doing the right thing for the company is not always good for your project, but ultimately it is the right thing to do for your career. Demonstrating to leadership that you can think globally about the company will ultimately help your career.

For most companies, the answer is wrong. When evaluating vendors, never forget to do some basic homework on their future roadmap, how it will affect your project, and how their roadmap matches up to your plan.

Here’s some things to do to prepare for major version changes during your implementation:

1) Managing the version change within your project plan and scope
If there is a version change or other major product upgrade in their roadmap, be sure that you put that in your project plan. Make sure that you put time in your project plan to evaluate the new product and adjust the project plan according to the requirements of the new product. You doubtlessly will have to upgrade to the new version to achieve support from the vendor at some point; it’s easier to change now than after you’ve gone to production with the product. Treat this essentially as a major change request would be treated, only you have the bonus that you know when it will (probably) be and can schedule this in your project. If you are tempted to put it off until after you go live, don’t. This is like all other major project changes. The later it happens in your project, the more money and resources it will take to implement.

2) Managing the version change and having the right resources
Do you have the right resources available for the new version? If the code base changes in the new version, you’ll need programmers and techies versed in that code base. You’ll need systems architects available when you evaluate the new version of the product so that you can determine if the new version requires more and/or different hardware. You will probably need a business analyst to look at the new features in the next version to consider how the way the product will be used by the company may change and improve. You may need testing folks to change their testing plans, if any are already written, and you will likely need your trainers to adjust any material they’ve done up to now.

3) Managing your resources before the version change
Do not make the mistake of doing work for the sake of having people work before the change in versions come down. There will be a lot of work that can be done beforehand. There will be some work that may become obselete with the new version as well. Evaluate your task list carefully. Don’t waste time sitting around waiting for the new version, but don’t waste resources working on things that will be rendered obselete either. It’s a careful tightrope to walk.

Last but not least, never forget to document, document, document. Keep up with your vendor’s version upgrade schedule. You will have to upgrade the product again after it is in production. This is a learning experience as to how to do that. Save as much lessons learned and project plan material as possible from your upgrade so that you can make your future transitions more smooth.

Vendor products change. This is a reality of their business model. Plan for the change so it can fit within your business model.

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.

People overlook easy things when faced with challenges. Some do it because they fear the difficult task, and thus their focus is on it and not the simple tasks before them. Some relish the challenge of the difficult. Those folks will overlook the simple stuff just the same.

Tough and difficult tasks in your projects will usually be done well- at least, to the best that your staff is capable of. They will bring their ‘A’ game, think, and pay attention. The tough tasks will draw attention and praise if done well. You don’t have to sweat these things- if your staff can do them, they will. Just put the right people on it and give it the right amount of attention.

The small things, on the other hand, can kill you. People assigned to the tough jobs will often slop their way through the easy tasks to get them out of the way. They’ll guess wildly at estimates, do the work too quickly, forget basic details and costs. Don’t let this happen to you. Sweat these details. Get the small work doublechecked, including the estimates. If possible, keep as much of the small work away from the people doing the heavy lifting on your project- not to help them do the hard work better, but to insure that the small work it done well.

Remember, a car will fail faster if you forget to tighten the lug nuts as it will if you don’t get the compression ratio of the engine just right. Always sweat the little things.

So it goes in IT and project management as well.  Too many times, we want the business to understand that we’re thinking ahead for them, that we’re using the right technologies, making good decisions, and sometimes the business simply does not care.  It’s not that they don’t want us to make good decisions, its that that’s our job, and they don’t need to hear about it.  They need to know when we’ll make their jobs easier.  The key is understanding when you should simplify things for the client, and when you should not.  Here’s a few example cases.

When the Sponsor/client cares about the end result:

Sometimes, people just want their problem solved.  They don’t care that you’re using web services to solve their problem.  They don’t care about the database.  They don’t care about anything except solving the specific business problem that they’ve identified.  What you should report to them is when you’ll be done, when the documentation and training will be available, and when you think they’ll be able to put the solution to use.  If this is what your client wants, then anything else other than updates to these three pieces of information likely just irritates them.  The result is everything to them.  If you talk about all the details you are wasting their time, and to them you are focusing on the process rather than getting them their result.  Stick to the basics.

When you are late on a project:

See the item before.  No matter how much the client may care about the process and the details when you’re on track, once you’re late, then they can get impatient.  Stick to the details of what you’re doing to get things back on track.  Don’t worry about the rest until you’ve solved that problem.

When your problems are not the client’s problems

The client’s problems consist of the fact that they don’t have their solution yet, what to do until it arrives, all the communication and change management around the solution implementation, training their staff, listening to their staff complain about things changing, learning how to use the new solution, providing training, and dozens of other things not related to your project/product.  The difficulties related to RPMs not compiling correctly on the linux installation are of no interest to them- that’s your problem, and that’s why you’re in charge of the project, not them.  In fact, there’s some chance that they don’t even care if you’re using linux, windows, unix, or bands of mongoose that quickly rewrite their screen every time they click on something new.  They just want their solution, and if you can tell them how you’ll make their other problems easier, that’s an added bonus.

Other times, you should share as much information as possible with the client.  Some examples are:

The solution will be delivered in phases

The client isn’t getting everything they want up front.  This complicates their lives.  Share as much as possible about what they can expect and when.

The client will be maintaining the solution after implementation

If the client has to maintain whatever it is you’re delivering, then you can’t give them enough information.  They will want and should have as much say as possible in as many decisions as possible.

All in all, understanding the right amount of information to share with the customer goes a long way towards their happiness.  Share too much, and you’re wasting their time and your own.  Keep your project reports tuned to the audience’s needs.

At the same time, Gantt Charts *can* be used in Agile Development.  Like in Agile Development itself, it’s all about adaptability.

The key is to learn to build your project plans in a modular way.  Within every project, even an Agile Development project, there are some tasks that simple must depend on one another and must be completed in order to complete a given goal.  To meet a specific business requirement, for example, you know that you need to develop function X, Y, and Z.  You know you must write requirements, you know you must write test plans, you know you must test, you know you must release them.  If you intend to deliver a complete solution for this business requirement within a single release, then that’s your module.  The number of iterations within that module, the order within that module, is not as relevent as the fact that you are going to do all of these tasks, and must do all of these tasks, in order to deliver a solution this business requirement.

So now that you understand something about a project ‘module’, how do you manage with it?  Try these steps:

1.  Develop your project’s task list as normal.

2.  When you create your project plan, organize your task list into modules.  Assign modules to software releases according to your current estimate as to what order that these things will be delivered in.

3.  When your project team, or your management team, shifts, then shift the modules within your project plan.  This WILL sometimes wreak havoc with your plan, particularly levelling and dependencies.  You will learn ways to adjust so that it’s easier (I could give pointers here, but really, I’ve learned that it’s heavily dependent on your style of PMing).

4.  Communicate, communicate, communicate!  You will need to constantly put out updated projections and updated task schedules when doing things this way (Agility does not come without a cost).  Your team must always know what’s coming next, so that the preparation work needed for it can be ready (for example, requirements for the next phase of development must always be ready before the developers finish the current phase).  Your management must always know how the delivery dates change, so that they can manage to the new schedule.

There is more to it than this, but again, it’s heavily dependent on your management style, and so your mileage will vary a bit.  Once you get used to it, it’s extremely effective- think of it as “Planning to not have a plan”.

By planning your modules carefully, and watching your dependencies to always keep the right ground work queued up, you can be ready for anything.  Your team will be ready to change directions on a dime, and be truly Agile.

There’s a saying I heard in a college psychology class that has stuck with me for life- “The most flexible part of a system controls the system.”  In the business world, the most flexible company in a market is capable of controlling the market (just look at Apple and Google).  Planning for Agility is tough- get used to it.  If you can pull it off effectively, you have a massive advantage.

This may sound jaded. You may say that things aren’t done that way at your company. You may be right. However, in most places, this is the way things happen. You need to know this for several reasons:

1) Understanding how things work help you function in the political arena of your company.
2) Understanding how things work can help you influence how things happen in your company.
3) If you are having too many meetings where no decisions are made, perhaps you should consider using these tactics yourself. Get the decisions made outside, then leverage the meeting to create agreement.

The third note may sound underhanded and overly political. If you do it well, it isn’t. Talk to everyone on your team individually. Get a feel of what they want. Gather facts from them. Use these facts to answer questions for others. You will find that if you talk to everyone and help them to get a perspective before the meeting happens, everyone will likely have reached a similar conclusion well before the meeting, resulting in a smooth, simple, quick meeting where everyone arrives and reaches quick understanding. If not, they are at least armed with more and better facts to discuss the topic.

Let’s say the business writes up a project proposal. They research their business process, identify key problems with it, define good goals for the project and turn a beautiful proposal over to you. Let’s say they spend a good, solid 6 months putting it together. They’ve done their homework. All you have to do is implement it.

But wait, it’s not that simple, is it? The proposal has to go to IT management (and possibly some sort of advisory committee) for approval. IT has, after all, dozens of projects on its plate, in most companies, and can only do so much. IT probably already has tons of projects started that are ahead of the proposal. Let’s say it takes 2 months to get it sold to management and approved.

Now it needs a budget. You can’t buy hardware and software without a budget, right? This is capital expenditures. It has to go through financial planning. Let’s say it passes their eyes with flying colors, again in only two months. That means that money is approved for it- starting next fiscal year.

Now that the project has a budget, it has to wait for staff to manage it. You can’t start the project without a project team. If you want to do the project effectively and efficiently, you have to take the time to search for and find quality team members. The hiring process of finding quality employees can take months.

Now work can begin, right? Wrong! You have a project proposal in hand, a budget, and staff. You need a project plan, project scope, requirements… you can’t build something corretly until you’ve defined exactly what you’re building.

As you can see, the list goes on and on. The business is impatient for a reason, and it is a good one. They need what they need now. They’ve asked for it, they’ve done their work, and now they’ve nothing to do but wait. And wait. And wait.

The business must recognize though that if they want IT to do a good job, they have to give them the time to do it. In today’s world, you must plan ahead. IT can give a business agility, but only with a lot of planning ahead to be sure the right things are in place at the right time. If you plan perfectly, sometimes you can just hand over a proposal and get a solution immediately, but odds are, it is going to take time.

Even if the solution is coming ‘off the shelf’ from a vendor, there has to be someone in IT who understands and can support the product. There has to be a server for it to go on. That server needs to be built, secured, put into the backup plan, disaster recovery plan… the list goes on and on. Solutions take time if they are to be done well.

You must also remember that it takes time for a good reason. If the business is going to use any tool, it *must* be reliable. There can be no excuses. Any unreliability is cutting into the way business is done. Cutting corners on implementation will always, always cut into reliability sooner or later with software.

The other side of this is that IT has to learn to be more flexible. More and more IT departments nowadays hide behind the project scope and requirements gathered at the beginning of a project instead of being guided by them. Business needs change over time. If they didn’t, IT would not be as valuable to the company as it is.
On the other hand, business changes. If it takes IT a year to get the project going, don’t be shocked if the business’ needs have changed already.

Be ready to adapt to the changing needs of the business, even during the middle of a project. Yes, these changes are expensive. Yes, they are a risk to the project success. Yes, scope creep can keep you from ever getting your project done. Scope creep happens, however, because business changes. If it isn’t changing, then you better be worried about your business, because it isn’t growing and evolving.

The bottom line for IT is this: building software for the business that they don’t need anymore doesn’t do anyone any good. Keep up with changing times and changing business.

The bottom line for business is this: Plan ahead. Don’t expect overnight solutions. Find the best solution to the problem at hand and learn to forecast problems in the future so that you can have what you need in place at the right time.

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.

Many project managers worry that they are not going far enough with their plan.  The opposite scenario is just as bad.  How can you tell when you’ve gone too far?  Here’s some criteria I suggest:

1) Client Satisfaction:  If the Sponsor, business owner, and other major stakeholders are happy with the results they are getting, but you are not and the processes that you’re using say you’re way off target, this is a warning sign.  There’s times when the project will get off the schedule you set.  There’s times when scope MUST expand in order for the finished product to meet the business’ needs.  There’s times when you’ll be dragged off schedule simply because (gasp) another project is more important to the company than yours, and you have to wait for resources.

If the team, the stakeholders, and the company are satisfied, and you are not, then something’s wrong.  If your PMO’s policies say that the project is at risk, but the everyone else says it’s not, then you need to re-examine your methods and criteria.  Reality is always more correct than policy.

2) Employee Satisfaction:  Do project team members avoid you when you approach, even if they’re not off-schedule?  Are people skipping your meetings whenever possible?  If so, you need to revisit your methods.  Project Management is about, above and beyond all else, communication.  Consider this:  Person A is an incredible communicator and detailed person, but they know nothing of formal PM process.  Person B is a terrible communicator but can quote the PMBOK in their sleep.  If you give each of them a project with a team of ten people, which one stands the better chance of success?

The truth is of course Person A.  Doubt that if you will, but the fact is that projects were accomplished for thousands of years before formal project management began.  The military carried out campaigns of brilliant coordination, timing and logistics without it.  It can be done without any of the tools.  The tools are useful and can make you more accurate, but they’re tools.  The craft itself is still in your organization, leadership and communication.

If people are avoiding you, there’s two possibilities:  either your tools are offending people, or your personal skills are.  You had the skills before you were a PM for someone to recognize your ability to be a PM, right?  I wouldn’t doubt those skills now.  Examine the methods you are using.  Talk to the people avoiding you and ask what they hate about the process.  Work to make the process work without being a burden.

3) Valid Outcomes:  If someone goes ‘off the reservation’, uses methods that were not part of the original project scope, but they achieve effective results that the business approves of and client is satisfied with, is that a problem?  If your methodologies say yes, then you need to consider your methodologies.  After all, you work for the company.  If the company says the new method is okay and so does the client, why don’t you?  What part of your process prevents it?

4) Over-Communication:  Believe it or not, this is possible.  I have been in a situation before, at more than one company no less, where I devoted more of my time per month communicating with the PMO than I did with two-thirds of the departments or people I managed- and in none of those cases were any of the projects I was involved with actually in trouble.  Any time that happens, the PMO is getting in the way of my effectiveness as a manager.    I’m no longer on my department’s payroll; I’m on theirs.  If we communicate that much, I don’t have time to pass on what’s communicated to my own team so that they can act on it.  How is that effective?  The data flow officially stopped at me- the team members below in the organization never got it.  The hyper-communication of the PMO failed because it choked the bottleneck (in this case, me).

Try to keep your communications, follow-ups, and meetings to what is truly needed.  This can be a balancing act at times.  It involves trusting people.  If you don’t, though, you will not only overwork yourself, you will create a self-fulfilling prophesy of failure- by monitoring closely the process too closely, you break the process.

These are examples of just four things that can go wrong if you go too far.  Choosing the right mix may seem like magic or art, but it’s not- it’s science.  All you need is observation skills.  Watch your team members and stakeholders.  Monitor their attitudes and what’s going on.  If people are unhappy, there’s invariably a reason for it.  Don’t drown the process in your attempt to manage it.

1) All leaders in the project give the appearance of being of one mind and that the project is in good hands. This inspires confidence from the team

2) It insures that new issues are held on to until they can be discussed thoroughly, before public dissension is created through knee-jerk responses

3) If other staff in the meeting bring up important info about the decisions you have arrived at previously that should influence your decision, treat it as a new issue. Talk to that staff, gather your facts at that meeting. You can now take that info away, discuss it at length, and revise decisions as needed. You can always release your final decision at the next meeting, again with a united front.

4) All disputes are held behind closed doors with the minimum number of participants.

This may seem like you are leaving a lot of people out of decisions, but remember this: if your project is moving at a realistic pace, you are always making decisions with the minimum amount of people involved. A working meeting is six people or less for a reason. This is the absolute maximum number of people who can hold a reasonably short discussion about anything and reach a firm conclusion. Anything more than that is simply information transfer.

With all the unforeseen disasters that seem to strike, you need to dodge every bullet you can.  Here’s ten simple things to remember when you build your project plan and your budget.  Some of these are elementary to the experienced Project Manager, but it is usually the elementary things that trip us up the most.

1.  How many hours per day do you allocate?

If it’s 8 hour work days, chances are that your plan is off.  People go to meetings.  They read email.  They help users.  They go to the bathroom.  Depending on your company’s environment, a more sensible assumption is 6 hours per day, even less if impromptu meetings are rampant, or if your project team members are responsible for operational support in addition to your project.

2.  People take vacation.  Did you check with them on that?

Your lead developer takes two weeks off during your project a week before you’re supposed to hit QA.  Your lead analyst schedules two days off during the time you were supposed to be meeting with the clients for a JAD session.  These are just a few things that can go wrong.  Make sure you check with every resource in your plan for vacation time scheduled.  Don’t just plan for the days off themselves; anyone connected to operations, for example, who is on vacation for a week is probably going to be useless to your project for at least a day after they get back as they catch up on all the problems that piled up while they were gone.

That brings us to…

3.  Plan for Personal Days and Sick Time

Not only will people be off on planned vacation, they’ll also be off for unscheduled days.  Personal days and sick time will pop up.  For example, some of the things that have popped up in the last year in my projects:

• Deaths in the family
• Ruptured plumbing
• Car Wrecks
• Divorces
• Child Births
• Company Celebrations
• Illnesses
• People moving homes

You get the idea.  People have real lives, and these things will make them be out of office at times that you won’t be able to predict when you write your original project plan.  Don’t forget to allow time for it.

4.  Holidays

This one should be blindingly obvious- remember to check your company’s calendars for time off for holidays.  In addition, don’t forget to check with any clients or vendors- if you need a client to be available for an implementation, and they’re out of office, you’re out of luck.  Also, don’t forget ’pseudo-holidays’ like election days, where your people will not be out of office all day, but they will be in and out, and they will be distracted.

5.  Don’t Forget the Weather

If you live in some parts of the country (oddly enough, the Southeast is a great example of this), you need to allow for the weather.  Here in Nashville, for example, any project during the winter months should realistically allow two days slack for lost time to inclement weather.  At some point it will snow- not necessarily enough to keep people from work, but if it keeps kids from going to school, then frankly that’s the same difference.

And just as an aside:  yes, we Southerners know that to everyone else in the world, it’s silly to close the schools when there’s an inch of snow.  We don’t do that.  We close schools when there’s an inch of snow, which turns into black ice due to our wierd warning/cooling days/nights, and there’s little or no proper road equipment to get the roads salted properly, and there’s thousands of idiots on the road who don’t remember how to drive on the ice because there’s only ice once or twice a year.  If it were our own lives at stake when those idiots slide all over the road and hit someone, we might just go to work.  That’s not the case.  It’s our kids’ lives when we’re driving them to and from school.  Give us a break…

6.  Items 1-5 will strike your clients and vendors

And you’ll never know until it’s too late.  Plan for this eventuality.

7.  Other projects will start.  They’ll be more important than yours.

When this happens, it may pull resources away from your project.  Be prepared to adjust your plan accordingly. 

8. Estimates never come in at the low end

People will give you estimates like “2-3 weeks”.  If they do this, the more realistic expectation is 2.5-3 weeks.  This is a natural extension of Parkinson’s law.

9.  You don’t really know exactly what you’re doing

Any worthwhile project will be embraced by your organization- and, as more people get interested and involved, they’ll ask questions, and offer ideas, and your requirements will end up changing.  If it doesn’t, you should worry.  Remember that when this happens, you’ll need to adjust the plan and come up with new estimates.  Don’t panic when this happens.

10.  Prices will change

Did you get a quote on those servers you’ll be needing next spring?  Too bad two months before you bought them, the vendor discontinued them, replaced them with something beefier, and jacked up the price 20%.  These things happen.  Remember to talk to the subject matter experts in your company and inquire on when price jumps typically happen, how often and likely they are, and what kind of spikes you might need to account for in the budget.  If you don’t have the expertise in-house, work with your vendor.  They want to make the sale, and if you don’t have budget, then they might miss out on that sale.  If you are up front with them, there’s a chance that they’ll help you out in predicting what will happen with their future costs.

You give a long report about what’s going on with the project, what the current status looks like, when you expect to deliver.  After you finish, you open the room up to questions.  No one has any.  At all.  After the meeting, you check with the sponsor- it’s an important sponsor – and he says he understands and is impatient for completion of the project.  After engaging him in conversation about the deliverables you are wrapping up, he asks some odd questions, you probe more… and realize he doesn’t understand what you’re about to deliver to him at all.  He’s working off assumptions.

This is (unfortunately) not an uncommon experience in the workplace.  The part of this situation I want to illustrate is how you learned what was truly going on:  by what the person asked.  Most people believe that they understand what’s going on- otherwise, they will voluntarily ask questions.  They don’t dodge asking questions out of any insistence on not knowing what’s going on.  You must seek what they don’t know- what they do ask questions about- if you want to know what they believe is going on.  Seeking inquiries and digging into details with someone will invariably lead you to their view on things.

It’s an old mantra, but it’s true:  Judge people not by what they say, but by what they ask.  Use this to your advantage.  Never be satisfied with just what they say.  Seek them questions.