In my best Andy Rooney impersonation, "Have you ever wondered what prevents IT projects from fully meeting expectations on time and on budget?" It may not be due to the software. It may not be due to the people. It may, however, be due to not paying sufficient attention to the speed bumps in the project lifecycle that present obstacles to the basic human nature in all of us.
his article, Who
to Blame for Project Failure? Look Up - Not Down, Not Left, Not Right. my
colleague, Olin Thompson, made a strong and articulate case that a project is
doomed for failure unless it has a top-level executive sponsor. I agree with
Olin, however, that having an executive sponsor is not a guarantee for success.
This article looks at several factors that can cause a project to fail or help it to succeed, namely: comprehensive planning, inertia/loss of momentum, sense of urgency, and commitment. Redefining the acronym, KPI, I call these factors, Key Project Impeders (KPI). I will describe several that are commonly found in IT projects and what you can do to avoid or surely minimize their effects.
This may appear to be a no-brainer. However, project planning is not simply referring to preparing a project plan in MS Project. A good project plan must be able to convey to the team members that there is a logical and fairly detailed approach that will lead to success. But equally important, the plan has to clearly specify what is to be done when and what are the expected results.
Human beings are comforted by knowing what they will be doing tomorrow and the next day and what is expected. Remember the feeling you had in college when the professor said, "Pop Quiz!" Specifically, at some point a plan needs to provide answers to questions like "What will I be doing?", "How long do I have to do it?", and "What do I have to give you when I am done?" For example, when preparing to complete the final training for the users, the following descriptions and task outline would be helpful to the team leaders responsible for conducting the training:
... 1 Objective: Train users in the use of the software to complete daily
... 2 Announce/Confirm training dates and facilities
... 3 Prepare training plan and outline
... 4 Develop training examples
... 5 Prepare training environment and data
... 6 Prepare training aides, material, and exercises
... 7 Conduct "walk thru"
... 8 Conduct training
Is it practical or even necessary to prepare this level of detail for every phase in order to issue a project plan? No, I don't think so. There is an axiom in project management that the more often dates are changed, the less believable they become. Accordingly, providing this level of detail for latter phases of a project plan, when initially issuing the plan, will most likely lead to constant changes in deadlines and deliverables.
Typically, the initial project plan would specify the detailed tasks and completion dates for the first phase. For the subsequent phases, the plan would indicate the planned start and completion dates for the phase and the detailed tasks, but without dates. Duration of the overall project would determine how far in advance the details for the next phase would be released. By the way, some of you may say that the example of the training tasks is not detailed enough. The detail and specificity of the plan and tasks vary directly on the caliber of the individuals executing the plan. Providing excruciating detail may be insulting to the team leaders and limit their creativity so I have learned from experience.
Inertia / Momentum
In every project and within every phase of project there is what I call the fear and floundering stage. This stage is not prompted by "What should I do?" but "How do I do it?" Inertia or loss of momentum can cause serious project delays or totally frustrate team members. Inertia can be prevented or minimized by providing action-oriented tools to spur activity and progress.
For example, in the user training referenced above, providing samples of outlines, presentation material, and possible exercises can break through "trainer's block." However, the best example is the area of software piloting. Often, a project team may have never conducted a pilot or, surely, not on the new ERP software being implemented. Therefore, it is not reasonable to expect the team to hit the track running unless they are given an assist.
In this case, you can provide simple business conditions for them to test. These conditions should test the basic functionality of the software and are not intended to fail. Rather, they should develop a familiarization with the software and encourage modifications to the conditions to test company-specific requirements. However, the person conducting the pilot will not have to worry what to do but simply, as Nike says, "Just Do It!" Momentum is maintained; the project is moving forward; and the team will feel more confident. Shortly, a flounder is simply another fish in the ocean.
Sense of Urgency
What was good about Y2K? Yea, it was over hyped and didn't happen to the extent predicted. But it gave projects a built-in reason for getting the job done by a specific date. There was a sense of urgency. The payrolls would bounce; general ledgers wouldn't close; and, of course, golf handicaps would explode. Seriously, it was beneficial to have a key event on which the project team could focus. At the time Y2K was a real threat. There was a sense of urgency for completing the ERP implementation project for the strike of midnight, December 31, 1999.
While projects do not have to be tied to life or death events, it is valuable that the project timetable coincide to real, tangible benefits. For a business-to-consumer company, it may be a new timed payment process that will increase sales. For another company, it may be a commitment made to external board members to have disaster recovery hot site in place before the next directors meeting. For a third company, it may be the promise to treat team members and their spouses to a weekend at a nearby resort. Whether it's increasing revenue, maintaining integrity, or preserving harmony on the home front, each has a positive effect on motivating the project team.
is not only having the time and ability to work on a project but being told
that it is OK to do so. Unless a company's management is willing to assign the
appropriate and, sometimes, the best talent to the project and convey this to
the project team, team members will spend more time worrying about their current
jobs that than on their future ones. This is why, as the project manager, you
must clearly define early on the level of commitment that it expected. Below
is a chart that you may find useful in conveying the expected level of commitment
to the project team and management.
- Project Planning & Organization
- Business Process Pilot
- Solution Integration
- Integrated Pilot
the project's executive sponsor is expected to, at least verbally, sanction
this level of involvement. Furthermore, assurance must be given to the team
members that the overall project's success is dependent on their involvement
and that this commitment been approved by senior management.
All too often we tend to overlook the human dynamics that make projects successful. When we do, we encounter the dreaded KPI's. More importantly, underestimating the human dynamics associated with a project will cause frustration on the part of team members and dissatisfaction on the part of the recipients of the project deliverables. This, in turn, can cause project delays and failure to effectively meet user expectations. You probably have encountered your own KPI's on your projects that appealed more to the nature of the human being than the nature of software and hardware. I would be interested in hearing about them and how you worked through or around them.
J. Strub has extensive experience as a manager and senior consultant
in planning and executing ERP projects for manufacturing and distribution systems
for medium-size and Fortune 100 companies in the food & beverage, chemical,
and CPG process industries.
can be reached at JoeStrub@writecompanyplus.com