5 Reasons Why Some Projects are Harder Than Others

As I’ve always said, no two projects are the same and all projects are not created equal.

While those are definitely not profound words, we still get perplexed sometimes as to why one project may seem so much harder than all the others. Why do some projects we are managing seem to go off without a hitch (that’s just a perception – they all have hitches), and then others can leave us struggling so much we come out the other side thinking “I am never going to go through this again”?

Related Article: Dealing With Difficult People on the Project Team

My take – from experience, observation and logic – has narrowed it down to five common problems that can make one project stand out from the others in terms of difficulty and issues experienced when all else seems to be about equal.

Please be thinking about your own experiences and reasons as you read these and feel from to share and discuss at the end. Here are my reasons:

1. Different level of complexity

While we think a given project was about the same as other similar projects we have managed or are managing, we eventually find out there was an underlying complexity to the current project that caught us off guard, made it stand out in terms of issues, pain and suffering. Often times when we find this out after the fact, we are faced with rework, missed deadlines, over budget issues, and customer frustrations that only add to the pain and suffering.

Usually this is related to requirements, but it may also be a product of not accurately or fully assessing the project client’s environment and the eventual integration that will be required as part of the project.

2. The unknowns outweigh the knowns

We may not immediately realize this – which can get us into a mess quickly – but the unknowns on the project may actually outweigh the knowns. In short – don’t start until you eliminate as many unknowns as possible!

Very early on – during project kickoff preferably – discuss assumptions and unknowns with the project client. Do they know their environment well enough to move forward? Do they know the real need well enough to move forward? Have they truly identified the real need? Do they understand the impact to the rest of their organization to move forward with the project and the proposed solution? If not, then the implementation phase is going to surprise you and everyone else and likely be very, very painful. You may satisfy one group of end users, and completely stop another group in their tracks who were not intended to be affected at all.

Seriously, if the project client comes in with more questions than answers, you may need to double or triple your planning phase time and budget, or you will live to regret it.

3. The customer is disengaged

While it may seem like a customer who isn’t around to ask questions and slow your team down during a technical project is a blessing, the exact opposite is, in fact, true.

You need the customer to be engaged. You need them available to answer questions, clarify requirements when you hit a questionable area, explain a business process you don’t quite understand, and take care of the project tasks that you have assigned to them.

Yes, many project sponsors have lots of responsibilities other than the project you are managing for them, but you need them available so that key decisions can be made and the project can stay on time and on budget.

4. The project team is in flux

When your project team is changing or being slowed down by other project responsibilities, team members may have it can cause major issues on a complex project that needs their attention and focus now.

Taking drastic action to replace distracted or overloaded resources is the last thing you want to do as it can be costly and time-consuming. If your team seems to be experiencing issues like this or internal conflicts, try to recognize it as early as possible and be proactive rather than reactive in fixing the problem. The longer you “wait and see if it will fix itself”, the more problems you will have. Rarely does it just fix itself. Rarely does anything just fix itself.

5. Project requirements lack the necessary detail

Project requirements are the lifeblood of the project engagement. They must be complete. They must be detailed. They must be understandable. And it would be nice if they were accurate. Poor requirements result in rework, scope creep, questionable change orders (whose fault is it, who should be responsible, who should pay?), and missed deadlines. It’s a difficult call especially at the euphoric beginning of a big project, but if the requirements are questionable, and you feel there needs to be more detail and work put into them, don’t move forward. Go back to the drawing board. Requirements are the basis for functional design, technical design, user acceptance testing, and ultimately project approval and sign off. If you don’t have it right at the beginning of the project, the rest of the project can be in question.

Summary / call for input

In reality, there can be about a million reason why one project is much harder to manage and control than another. What I’ve presented here are just five of the more common ones that can negatively impact just about any project in any industry.

It takes a confident, detail-oriented project manager to watch out for these, to halt the project when it needs to be stopped and assessed and to make the quick decisions and tough calls to get it back on track. The indecisive project manager may let the project proceed without stopping and taking proactive action leaving the project limping forward while hoping it will get better in the next phase. It won’t! You’re left with a project that ends up being more difficult than the others and more difficult than it needed to be.

What about our readers? What comes to mind as to reasons why some projects you’ve managed have been harder than others when the project may have seemed to be about the same as others you’ve taken on? What can turn the tables? Please share your thoughts and experiences.