28 February 2007

Tell Them What to Do But Not How to Do It

Until this title is put in context, it seems like a strange position for anyone to take. It sounds
like you are leaVing your team holding the bag. Bear with me though.
The idea for this article came from the June 2006 issue of CIO. It had an interesting cover
story that I can't help but add my two cents" worth to. "When Failure is Not an Option"
chronicles the evolution of A.G. Edwards's IT project management from an historical 54%
failure rate to an 88% success rate. The article attributes much of that success to John Parker,
the newly hired CTO, whose objective was to effect that change. The change is certainly
remarkable and I don't want to detract from Parker's accomplishments in any way. The
turnaround that he engineered deserves our respect.
Among the many valued changes that Parker implemented, one stuck out in my mind. Parker
stresses that a successful project management methodology defines what has to be done but
not how to do it. That is left to the project manager and the individual team members. While I
agree with what Parker advocates, I don't think he goes far enough. I'm not comfortable
leaVing it entirely to the project manager or the individual team members to decide how
something should be done. That flies in the face of a learning organization and certainly
doesn't make repeatability a characteristic of the organization.
I have always had good success with the idea of a best practices kit. This would be a collection
of tools, templates, and processes from which the project manager could draw from as best
fits the situation. The existence of a kit narrows the how to a choice from among a closed set
of tools, processes, and templates. The contents of the best practices kit would have to be
vetted before they could be used. Only vetted best practices could be used by the project
teams. They are not free to choose something outside of the best practices kit. It is my
opinion that that makes for a more mature project management organization and certainly
one that could learn from its experiences.
So where does this best practices kit come from? There are three primary sources: best
practices from within the organization itself, best practices from outside the organization, and
best fit for each project class. The toolkit is dynamic. It changes as the experiences of project
managers and their teams mature and develop. The in process and post-project audits help
further develop the best practices kit.
Internal Best Practices
The internal best practices are the practices that are developed within the organization. They
may be defined in the project management methodology or may be practices that have
evolved through repeated use in a variety of circumstances. In any case they are home-grown
practices.
External Best Practices
The external best practices are those that people brought with them from their previous
employer, that they learned in a workshop, that they read about in the literature, or heard
about from a variety of other sources. In any case, they came from outside the organization.
They were adapted to the organization and used successfully by their owner on an
organization's project.

Best Fit for Project Class

This may bear some connection to the previous two sections but I put it here for
completeness. These practices were used successfully on projects of a certain description: lowl
medium, or high risk; small, mid-sized, large, or very large; simple or complex; critical
mission or routine repeated projects.
What to Do with These Best Practices
Obviously, there needs to be a place to archive these practices for use by all project teams. I
don't suggest a dumping ground for anything a person wants to include in the toolkit. That is
counterproductive and leads to confusion. Rather, the toolkit needs to be vetted, indexed,
monitored, controlled, and maintained.
Documenting what is in the best practices kit is the first order of business. The documentation
format must be standardized for ease of use. That standardization should include the process
step that it applies to, a descriptive name, the class of project for which the practice is a best
fit, a full description of the practice including any templates or process descriptions,
experiences in using the practice, and the name and contact information of the person who
submitted the practice.
The resulting best practices kit will be a collection of tools, templates, and processes for use in
projects. Every practice in the best practices kit will have passed muster as an entry
requirement. There should be several practices for each project phase or artifact. The project
manager or team now has some options on how to do something that the project
management process requires them to do. They are not told how to do it! however. That is
their choice within the bounds of acceptable practices. If it is in the best practices kit, it is
acceptable for use as determined by the project manager or team.
Using the Best Practices Kit
Faced with a situation for which some assistance is required, the project manager or team
member can consult the best practices kit for any practices that might be useful for the given
situation. Suppose such a practice is found. I would say that it is very unlikely that a practice
can be used straight out of the box. That means adaptation. How might the practice be
adapted to improve the likelihood of a successful application? I have always preached that
effective project management is not much more than organized common sense. For the best
practices kit, that means to assess the practice and make it fit the situation. If in fact you start
with a best fit practice, it should not be far off the mark of being the actual best fit practice.
These adapted best practices are then candidates for addition to the best practices kit.