Project Management Blog

1. Poor planning:
Who are your IT managers and do they get enough opportunity to plan or under pressure from senior management they tend to think planning as a waste of time because they believe that time is better spent doing something rather than planning. Do you involve your project team in planning? Do they have the skills and experience to make complete plans? Or you always ask them to implement the solution. These are fundamental questions that need to be answered first.

2. Unclear goals and objectives:
Many IT projects are elaborated progressively and in these scenarios project managers rely on rolling wave planning. As a result, the goal of a project may be only partially clear due to a poor requirement gathering in the definition stage of the project. In such case, the scope and schedule developed by project managers cannot possibly be accurate because their objectives are unclear. Defining clear requirements for a project can take time and lots of communication.

3. Poor Stakeholder Management:
Project stakeholders’ interests may be positively or negatively impacted by the project and that is why stakeholders’ influence on the project is the most important thing to consider. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly.

4. Scope creep and Feature creep due to objectives changing during the project :
Uncontrolled and unexpected changes in user /stakeholder expectations and requirements as a project progress always negatively impact a project. This is known as scope creep. Many times new features are added to the project with a wrong assumption that one small feature will add nothing to cost or schedule. This unplanned addition is called feature creep.

5. Unrealistic time or resource estimates:
Many times project managers make costly mistakes while estimating time or resources. One common mistake is made during the creation of the Work Breakdown Structure. Often it is assumed that the time on task equals duration. Project managers estimate the time on task is the time the task will take to complete. How about interruptions? Some may be known and some may be unknown. Do project managers anticipate interruptions? In reality duration is the time the task actually takes to complete including interruptions.
Another common problem is using linear approximation when estimating the schedule For example, if you double the number of developers, you can cut the project time in half. In reality, doubling the number of developers produces a non-linear result.

6. Improper delegation of task and responsibilities:
Many times project managers fail to delegate tasks and responsibilities to the team in such a way that they should fit team members' job descriptions. When team members are asked to work outside their specialization (often as added responsibilities), they not only go through a learning curve but also tend to lose focus on the project objectives. This always results in confusion among the team members and eventually cost and time overruns.

7. Lack of executive support and user involvement:
IT managers face many difficulties in managing projects and the lack of executive support and user involvement are the two main reasons of IT project failures. Many times IT project managers work as project coordinators or project expediters and without executive support they cannot personally make and enforce decisions. The second reason is user involvement and often the project planners fail to plan human solutions to the very human users that the product is proposed to serve.
8. Failure to communicate and act as a team:

Projects sometimes fail due to improper communication. Many large IT projects are so complex that these projects always require large amount of analysis and work. The project teams are busy doing the analysis, creating WBS, time estimation etc. and project managers do not communicate progress regularly because they believe that progress will not be seen by the executive management or they fear of improper reporting.

9. Lack of proper risk management:
Another potential cause for project failure is the IT managers’ inability to categorize all the risks qualitatively and quantitatively and implement corrective measures.

10. Inappropriate skills:
The rapid changes of the technology-driven business environment and the constant changes of technology make it hard to predict skills the IT department will be needed.
Almost all large IT projects require a diverse range of skills. Many teams lack the breadth, and depth they require. Also dearth of qualified people in the labor market and high attrition rate of the industry add many problems to the projects. Often, projects mangers spend substantial amount of their time in recruitment related activities.

There is an old saying in software development about how the only bug free line of code is the one you don't write. While this may sound pessimistic, the motivation is to curb a developer's urge to over engineer a solution. When it comes to Project Management, do we have a corollary to this wisdom?

I believe we do, and it is this: The unnecessary meeting that is cancelled retains productivity. (Or at least, it has the potential whereas the meeting would have certainly doomed the group to wasting an hour)

Meetings are a necessary evil. This is so because good software requires communication between developers and stake holders, but meetings should ultimately be seen as overhead. If five people are in a meeting for an hour, this represents five person-hours not spent on features or fixing bugs. Scott Berkun, in The Art of Project Management, goes a bit further and warns against recurring meetings, which often outlive their usefulness.

There are several ways for a Project Manager to keep developers out of meetings:

• Sit down with developers and stake holders separately and confirm if all expectations are met. A five minute discussion with both parties separately may save everyone from a longer project review session.
• Start eliminating recurring meetings, or convert them to opt-in meetings, decided by the Project Manager
• Structure the order of events in a meeting so that some persons may leave early. Don't make developers suffer through a budget discussion if all they need to do their job is clarification on the software requirements.

Before you get too slash-happy, do keep in mind that effective meetings can add value. A Project Manager should enable developers to produce software. If the meeting doesn't serve this goal, adopt some meeting elimination tips from this article.

This weekend, I picked up my issue of the IEEE Spectrum which they've devoted to software failures and started reading the fascinating article: Who Killed the Virtual Case File? It details the FBI's failed Virtual Case File System from its start to its mind-numbing $170M collapse into a steaming pile of unusable code, 800 pages of recommendations, and quite a few destroyed careers. It's absolutely stunning with respect to poor project management, so I'm going to focus on this article for a couple days to lay out where some of their biggest mistakes were and potential ways the risks could have been mitigated.

About halfway through the article, this quote floored me:
Mueller blamed himself for the delay, because he'd asked for an accelerated schedule. But Higgins blamed Mueller's staff for not being straight with him about his agency's ability to deliver what he wanted.

"Did somebody come to you and say, okay, Mr. Director, sir, you can have it sooner, but it's going to cost you this much more money or you're going to have to do without something?" Higgins remembered asking Mueller. "And he said, 'No, nobody ever told me that.' And I said, 'Well, lesson No. 1: faster, cheaper, better. Pick two, but you can't have all three.'

Wow.

Yesterday, I offered some points about What Project Management is Not and I promised to tell you what Project Management Is... and away we go:

Project Management is a seatbelt.

Just like a seatbelt, a good set of Project Management practices and a good plan won't do much if you're caught in a catastrophic situation. For the minor fender-benders and even bigger problems, it will definitely assist, and potentially provide some safety measures and even an escape route or two.

Project Management is a sign of something more.

Going back to the seatbelt analogy, if you put on your seatbelt as soon as you get in the car, I *believe* (no quantitative data to back this up) that you are more likely to be a safer driver. If you habitually perform good project management practices, you will be more likely to detect problems early and have a response plan in place.

Project Management is required.

For any project that involves more than a few hours of effort, some sort of planning is needed. The planning required is directly proportional to the size of the project. If the project consists of writing a new report this afternoon, the "planning" might be 5-10 minutes to think about it. If the project is version of your system, the planning will involve more people and more time. If the project is a $170M system for a major government agency, the planning will involve representatives from numerous meeting repeatedly throughout the lifecycle of the project.

Project Management is about sharing information.

Personally, I don't care if you use a text file sitting out on a shared drive somewhere. There are better tools available, but the point of all of them boils down to making information available to the required people at the required time. It doesn't matter how great your tools are if the decision makers can't get at the information they need.

Project Management is purposeful.

At some point in every project, a decision will have to be made that others are not going to like. In order to have credibility for cutting features, requesting more resources (time, money, people, etc), or pushing back against requirements, the information needs to be available to state unequivicolly "If we do/don't do X, the project is going to suffer in area Y."

Project Management is ongoing.

von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know that last point is a repeat from yesterday, but it bears repeating. Just because you have a pretty Gantt, PERT, or Critical Path diagram on the wall means precisely nothing. As soon as the project begins, there should an evaluation of your Estimates vs your Actuals. Maybe your estimation technique was off, maybe a supporting vendor moved faster/slower than you expected, or maybe a new product is replacing some of the planned work.

If you're not regularly reevaluating the plan, you're not managing... you're coasting.

Project Management is Not a Silver Bullet.

Project Management will not ensure success. It will not make you finish the project early, to spec, under cost, and appease all your customers. Sure, all these things can happen, but Project Management tools, practices, etc, etc only allow these possibilities, they do not guarantee them.

Project Management is Not an afterthought.

If your project is out of control in terms of scope, time, money, or all three, it may already be too late. If you where flying off the road into the nearest tree, would you say "Hmmm... I think I need a steering wheel." Why is the control of your project treated the same way?

Project Management is Not optional.

I use dotProject for everything ranging from my major clients to simple upgrade tasks on CaseySoftware, CodeSnipers, and here. Excessive? Maybe. Does anything get left out? Not a chance.

Project Management is Not about tools or pretty drawings.

As a core contributor to dotProject, I have a personal and even financial interest in everyone using it, loving it, and naming their kids Gantt and Critical Path. But I don't care what you use, but use something. An Excel spreadsheet would be a step up for many people.

Project Management is Not a random process.

Project Management is about planning. It's about knowing the status of tasks. It's about taking measured risks and having plans to mitigate those. It's about looking at the cold hard facts of the project and sometimes having to say "We're not going to make it."

Project Management is Not a one-time action.

von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know, this sounded harsh, but I'm trying to make a point. I have worked with and for many companies who say "This time it will be different! We have a Project Plan!" like it means something. Well, let me tell you something: It doesn't.

Tomorrow I'll get into talking about what Project Management actually is and why you need it.