Leadership

Don't determine IT project rigor based on arbitrary project size classifications

Rick Freedman isn't a fan of arbitrarily dividing projects up by size. He believes the classifications may suit the expectations of managers and salespeople, but they don't match the reality of on-the-ground project work.

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% 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."

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

1 comments
Anticlue
Anticlue

I think a key point here is to have a well defined standard to ascertain minimum documentation needed. Perhaps the organization needs to derive a project sizing document? This document would weight and rank the key parameters. For example, is this a new technology for your organization? Weights with answers 7 ? New Technology for the Industry 5 ? New Technology for the Organization 3 ? New Technology for this site 1 ? Site is familiar with this technology The document should be completed as a primary step in initiation and perhaps again after planning. It would be useful to mature the project by identifying the need for the project management needed. A key item to having the level of documentation match the work required. The project sizing document would recommend needed documentation. This type of tool and process would be very help in organizations which are in the adhoc state of project management maturity. Once a standard is in place it would help to define a repeatable process. Hope this helps, Elyse http://www.anticlue.net/

Editor's Picks