As we all know by now, information technology service projects in today’s enterprise continue to have abysmal results in terms of achieving time and budget goals. In fact, most would go so far as to term project management as more of an art – albeit a failing one – than as a science.
Rather than stopping their incessant “firefighting” and focusing on this downfall, middle management instead typically throws up their hands and blames unqualified technology workers. Where they could choose to enhance their own PM skill sets, and that of their teams, they instead continue throwing money at the existing symptoms, blaming the effects rather than examining the real causes. Is it any wonder then that technology projects continue to “fail,” or that senior management turns to radical alternatives such as outsourcing, which in effect ships business value (knowledge) elsewhere?
Well, true project management is a science. But what’s the most overused term in today’s business lexicon? If you answered “consultant,” I can’t really fault you, but this author would argue that the term “project manager” is starting to give the term a run for its money. Does anyone working in corporate management not get referred to as a project manager of some sort? But when one reviews these roles in IT departments, they usually find that what organizations describe as project manager roles really turn out to be a whole host of traditional middle-management roles. One could argue, therefore, that most titled project managers are not skilled with true, formal PM processes. Not skilled to the degree that project managers are in construction industries, for instance. And this absence is a root of the problem in that technology departments from the outset place ultimate responsibilities in unqualified hands.
I have come to believe that the only common skill / experience to be found in most technology department project management jobs is general ‘people management.’ I refer to this more general skill as Team Leadership. Team Leadership – alone – is not project management. The ability to lead people is but one component of project management, and not even the most important one (resources can better lead themselves, frankly). Let’s stop just promoting great ‘people managers’ into high-risk PM roles, without insuring they have adequate skills for the need.
Good project planning also requires embracing true PM toolsets, not just pretty pictures. How many times have we seen (poor imitations of) Gantt Charts in PowerPoint presentations? This is fine if one just insists on needlessly “simplifying” things for executive managers – though personally I think that is short-sighted. But I have yet to find a way to report actuals against a PowerPoint slide. My point is: Take the time to devise the plan in an appropriate tool, and continue to use it through the duration of the project. If your PMs aren’t well-versed in creating plans/schedules, then they aren’t PMs to begin with (see above). So get them trained. There are numerous methods available, as simple as well-written books on existing tools, to full certification programs.
Once PMs have some of this appropriate background, the key steps to successful planning are, in order:
1. Lay out methodology in sequential steps
This is known as a Work Breakdown Structure (WBS). Just a task list, that’s all.
2. Create a pool of all available resources
This is not always as simple as just the main team. It is anyone who will be responsible for the tasks listed in step 1. So this can include departments outside direct control (networking, training, etc.) and even end-users. Since time is money, this is also where one establishes rates for resources, in order to track financials.
3. Assign the now-identified resources to all the tasks identified in step 1
An important note to keep in mind at this step is that the old “to lessen time add resources” theory definitely, and quickly, reaches a point of diminishing returns.
4. Have the resources estimate their tasks
This is important, yet not always done. Having the resources assigned to tasks estimate their own durations serves to provide ownership, and increases team “buy in.” But most importantly, it increases accuracy. Will there still be under and over-estimation? Sure. But not as much as there will be if hands-off PMs do all the estimating.
5. Assign a deliverable outcome to each task, preferably in the form of a hard artifact
A simple question proves the need for this: If you can’t point to an actual outcome of a task, how do you know it succeeded? Or is complete?
6. Strictly define dependencies between tasks
This is where many plans, if they even make it this far in the creation process, really tend to break down. The important thing to remember here is to focus on the task dependency, not the resources. Just take it two at a time: Can task #2 begin at the same time as, during the middle of, or only at the end of task #1? And repeat.
7. Set up project calendar
This merely means indicating any “unavailable” time, for groups of people (company, department, etc.), or individuals.
8. Level the plan
This is where resource dependencies will come into play. This can be complicated, and is where true PM tools earn the most return on value. But nonetheless it is really just ensuring that resources aren’t “double booked,” in terms of time. Rule of thumb: In the plan, no resource can do more than 1 task within a given hour of time.
9. The resulting time frame, and end date, is the only correct one
I realize many in management will not want to hear this last point. But as we established earlier, the old “we have to have it by date x, now go plan it” routine hasn’t worked. Only once the steps above are gone through, with the maximum (but accurate) level of resources, can the real end date be known.
At this point you have a good underlying plan, that you can have confidence in, to start working from. Now managing the plan becomes a whole new battle, one that includes having the flexibility to incorporate changes of scope, resource-mix changes, and tracking actual time against estimates. That is a subject for another time, but suffice it to say, without a good, accurate plan to begin with, you don’t stand a chance to accomplish the actual management of it.
There is no reason to accept that projects can’t be envisioned, constructed, and deployed in a manner that realistically meets business expectations. If we correct past errors in PM job/role assignment logic and accept that it is possible for technology projects to succeed, maybe we can begin to tear down the walls that have come to exist for projects in the business technology arena.