Depending on their objectives and environment, projects vary widely in their complexity. Consider two walls, both 500 square feet in size. One spans 100 feet long and 5 feet high; the other is 10 feet long and 50 feet high. Will the design and construction of each wall take the same amount of time, resources and tools? Does each carry the same risk?
The height of the first wall doesn't require elevating the masons or the masonry, and therefore building the wall requires no scaffolding. This wall is the less expensive of the two and involves less risk. The second wall is a more complex undertaking. Builders must give the design, materials and scaffolding serious thought in light of the wall's height. The structure needs a crane to raise the masons and masonry to its high end. The wall also requires workers with more extensive skills and involves a higher degree of risk.
In many IT-business projects, complexity is discovered as work progresses, which results in missed deadlines, budget overruns and thwarted customer expectations. It is important that the project manager ascertain, and clearly communicate to the customer, the complexity of the project up front. Doing so will result in more accurate project costs as well as resource and duration estimates.
In assessing project complexity, imagine that the project has two dimensions: business and technology. Each dimension has a set of attributes that can vary in number depending on the project. The complexity introduced by each attribute can be scored on a scale ranging from a low of 1 to a high of 4; each of the two dimensions has a composite score that, when plotted on a two-dimensional chart, depicts the project's business and technical complexities.
Each project is driven by its own level of business complexity, such as competitors, cross-functional interactions, current business processes, customer buy-in, financial exposure, geography, regulatory restrictions and so on. Each attribute should be assessed on a complexity continuum, from low to high. For example, well-defined and static business rules mean a low level of complexity (a score of 1), while yet-to-be defined or dynamic business rules indicate high complexity (a score of 4). Similarly, if the product is to be distributed in existing markets already familiar to the organization, the complexity is low; distributing in new markets brings higher complexity.
Every project is driven by its own attributes of technical complexity, such as security needs, stability of hardware, and software, transaction volume, project team experience, and level of technology integration, among others. Whereas integration of a few familiar technologies would constitute a low-complexity task (a score of 2), integration of a large number of disparate technologies from various vendors indicates high complexity (a score of 4).
The complexity assessment process is dynamic, and a project's complexity should be reviewed and updated every time key changes take place (e.g., major changes in scope, resources, technology or corporate strategy). Understanding any project's business and technical complexities helps in assembling the right sponsors, project manager and team, as well as the inherent risks. Determining the overall complexity should factor prominently into the decision whether to proceed with the project. So here is my advice to project managers: Don't take on a project whose complexity outstrips team capabilities unless it is a prototype and the only goal is to learn from it.
Gopal K. Kapur is president of the Center for Project Management in San Ramon, Calif., and author of Project Management for Information, Technology, Business and Certification. To comment on this story, email [email protected].