Don't determine IT project rigor based on arbitrary project size classifications
Wednesday, July 01, 2009 11:30 AM
Such classifications may suit the expectations of managers and salespeople, but they don't necessarily match the reality of on-the-ground project work, argues Rick Freedman.
When IT project managers recommend using a rigorous project methodology, it's common to hear the all-purpose methodology nullifier from the client or salesperson, "But this is a small project!"
The inside project manager hears this phrase when he tries to convince the project sponsor that a project plan, a materials list, and a written scope are necessary. The external IT service provider hears it from the salesperson when she tells him that the new engagement he's selling should include an additional 15 percent estimate for project manager duties.
I don't necessarily disagree; there must be a dividing line between projects that are complex and critical enough to require a full, rigorous methodology, and those projects that are simple and routine enough to be managed with minimal project overhead. The question is: Where is that line?
To find the line that separates a truly small project--that is, one that can be run with a minimum of process overhead--from projects that require the formal discipline associated with a complex engagement, we first need to look at the familiar three constraints of any project effort: time, scope, and function.
Is it possible to simply set an arbitrary division? For instance, are these projects by definition small: Projects under two weeks in length; projects with a scope that doesn't require making changes to the existing data center architecture; or projects with functionality that the organization has used in production before?
I've worked with firms that tried to set cut-and-dried parameters for project size and set guidelines that, for projects that fit these criteria, no formal project plans, scopes, or estimates were required. My experience with these pre-set standard conditions has been negative; they didn't serve the purpose of eliminating debate about the requirement for project oversight and, more importantly, they attempted to defy the central reality of IT project work: All projects are different.
As any experienced project manager knows, the criteria that define a project's complexity are, well, complex. Beyond time, scope, and function are all the other parameters that project managers look at to prepare projects for success, which include the following:
- Is there a complex mix of technologies that could introduce risk?
- Is the stakeholder community involved, participative, and enthusiastic or reluctant and passive?
- Is there active sponsorship at the executive level, or was this project thrown over the wall with a hearty "good luck"?
- Are there multiple subcontractors and subject matter experts who need to be managed and motivated?
- What about personnel risks, such as one key individual whose loss would be devastating?
The range of risks and complications goes on and on. Here are a few factors that I consider when I'm trying to determine the level of project rigor that a particular effort requires:
- Technical complexity: For projects that use existing, well-known technology and are not applying that technology in unique and creative ways (e.g., a simple version upgrade), it may be safe to limit the use of detailed project plans and project management resources.
- Stakeholder participation: Projects that require limited stakeholder involvement, such as utility implementations in the data center, could minimize the stakeholder participation elements of the engagement, thus limiting project overhead.
- External vendor support: Projects that don't require specialized outside expertise, and so don't call for the involvement of external vendors or subcontractors, usually require somewhat less communication and management oversight to keep the team on the same page. If the team has successfully worked together in the past, this substantially minimizes skill and personality risk.
- Sponsorship: If clear and robust executive support exists, and the need for persuasion and constant status reporting can be eliminated, that also factors into my consideration for the amount of project discipline required.
- Criticality: What's the risk if this project goes badly? For projects that touch the central competitive or regulatory elements of the business, applying less rigorous project methods can be reckless.
- Innovative nature: I visualize a sliding scale of innovation when I review a project. Some projects, such as the twentieth Windows desktop migration, have a very low degree of innovation, and therefore the degree of risk and oversight diminishes. A project that attempts to invent something that has never been done before is inherently riskier, so call out for either an agile approach or a disciplined project management method that attempts to control the risk.
In my view, risk is the central equation that delineates projects that can be handled with reduced rigor and overhead from projects that require either an agile approach or a disciplined project methodology. I'm not a fan of arbitrary divisions into small, medium, and large projects; I think they may suit the expectations of managers and salespeople, but these classifications don't match the reality of on-the-ground project work.
Balancing the need for rigor and the requirement for speed and efficiency is one of the key skills of a project manager, and this skill is demonstrated by analyzing the unique requirements of each engagement, not by setting some subjective set of rules and applying disciplines only to those that fit "under the wire".
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant". Rick is a director in the Global Services Division of NEC America, and a trainer and course developer in the Agile Project Management practice of ESI, the international PM training company.
There are currently no comments for this post.