The application of Microsoft Project as a scheduling tool within the construction industry is limited, although it is growing. Historically, Primavera (now Oracle Primavera) has dominated the construction scheduling industry, while Microsoft Project has gained much greater acceptance in the IT and Product Development marketplace.

I wonder about the difference in adoption rates between these two dominant software tools for project controls and scheduling. I was told by a senior Microsoft Executive that MS Project is a billion-dollar-a-year business for Microsoft, with over 40,000,000 copies in circulation. I also wonder what percentage of these licenses are accessed on a regular basis, and about the underlying quality of schedules developed using MS Project.

In both IT and construction, there’s a body of knowledge describing the proper methods to use when planning a project and creating a schedule. However, while it is common practice in the construction industry to create a detailed baseline critical path schedule, it is not common practice in IT. In all of my interviews, I found the application of critical path scheduling to be minimal in IT projects and ubiquitous in construction projects. Scheduling seems to be one of the areas of project controls which differs greatly between the two industries, which begs a deeper analysis. Why is a tool which is considered essential in planning and reporting progress on construction projects virtually unused in managing IT projects?

One IT executive related his attempts to instill a scheduling ethos into his organization. When asked if his organization uses Critical Path Scheduling he responded,

“No. We often have a Microsoft Project schedule laying out the resources and WBS. However, it is not a tightly disciplined CPM schedule to begin with, and it is not updated throughout the project. There is value even in this level of scheduling effort because it forces the PM to think about WBS and resources.”

Much of the discussion with IT leaders about CPM focused on the difficulties in estimating level of effort for the creative process of software development, and the difficulty in creating and maintaining a CPM schedule. The measurement of progress in software development efforts has been an intractable problem since programming began. A single line of code can take a week to develop but could solve a month’s worth of development challenges. This area of intellectual inquiry is covered thoughtfully in the book, The Mythical Man-Month.  An IT manager defining, then scheduling an IT project is quite different than a seasoned construction expert estimating the amount of time needed to install an interior door, counting the number of doors which need to be installed, then assigning a level of resource to the task of door hanging.

Some would say herein lies the real crux of the sociological resistance within the IT industry to developing and progressing CPM schedules to track project progress. If the amount of time needed to complete a task is essentially unknowable, then what is the point of developing and progressing an arduous, Byzantine schedule that is nothing more than a work of fictive numerology?

If the problem is considered more carefully, this argument against disciplined scheduling in IT is clearly specious. The fact is that most software development does not break new and uncharted ground. For instance, the well-traveled ground of database schema development should be predictable to the same degree of precision as door hanging in construction. If one knows approximately how many tables, fields, indexes and links will be needed, then one can estimate the amount of time it will take to develop the database and then apply resources to the task in order to control the duration of the activity.

In every IT or construction project, there will be areas of risk where the answer is not fully known at the inception of its development. In construction, this is area is called “unforeseen site conditions.”

Both the construction and IT industries have the tools and processes needed to cascade a design solution over time with iterations that will mitigate schedule risk. What, then, are the key drivers that lead construction to embrace CPM and IT to eschew it?

Without further research, it is impossible to state the reasons behind the different adoption rate within construction and IT. A good place to start looking can be found in the words of Mark Felt, the famous informant from the Watergate investigation, who sagely recommended to Woodward and Bernstein, “Follow the money.”

Projects of all sorts will be late or fail completely for all kinds of reasons. But in the construction industry, contract documents control the distribution of both blame and money, based in part on the critical path of the project schedule. A standard construction contract will have language describing “GCs,” or general conditions. This is the amount of money per day which the construction company is entitled to be paid during the life of the project, based on the cost of maintaining jobsite supervision and project-related infrastructure, such as a jobsite office. On the owners’ side of the contract, there is a clause describing liquidated damages (LDs). LDs establish the amount of money to be charged against the construction firm for each day that the project is delayed – if the delay was caused by the construction firm. When a project is delayed, the question quickly becomes, “Who delayed the project, the owner or the construction firm?” Often, both sides use the critical path schedule in such a dispute to demonstrate that the project was delayed by one party or the other in order to seek compensation for the delay. The IT leaders interviewed for this research indicated no such critical path schedule as a key driver in most IT industry contracts.

  • Murray Woolf


    Systems Design is the “black hole,” not so much writing lines of code. Again, the better comparison to building creation is its Design, not its construction. IT projects range in up front uncertainty. Sure, some are revisions to existing releases. These are not the ones so hard to estimate. It’s the new concept programs that defy early scope certainty. This is why Agile came into existence.

    Why I think this article is nevertheless important to our understanding of the applicability of “Planning and Scheduling” as a disciple, is that it underscores a major value difference in the two areas of project management focus. Was it Eisenhower who said that, “plans are useless, but planning is indispensable?”

    What this article emphasizes is that in every industry that projectizes its approach to business performance, there is value is planning. There may not always be as much ROI in detailed scheduling however. And this revelation should temper anyone who would insist that “detailed scheduling MUST be done.”

  • Murray Woolf


    And IT, like any R&D effort is, in the main, an uncertain enterprise. The article contrasts software development with building construction (hanging doors), but a more comparable example would be building design. Truth be told, CPM scheduling is far less common in the design phase of a project than in the construction phase. Why is that?

    The article may suggest one possible explanation, contract terms and conditions. It is rare that an architect is threatened with liquidated damages. They do not have to submit a formal time extension request with each Owner change, as contractors must. Design phases are notorious for overrunning their allotted time, and encroaching on procurement and construction phases.

    Why the blind eye by the Owner? Why the double standard? I think part of the answer lies in the nature of the work. While the author makes a point that enough databases have been constructed for an experienced SD team to reasonably estimate the time needed to create a database, in my experience that is not where the uncertainty lies

  • Murray Woolf

    Kudos on a thought-provoking article. It forced me to sit back and think. As I did, several interwoven thoughts surfaced.

    The article cites the differing popularity of MS Project versus Primavera in the IT and Construction industries, respectively, as a credible correlation with how tightly each industry embraces the Critical Path Method (CPM). It then suggests that IT schedules are used to manage resources and clarify scope (WBS). Quoting an IT manager, the author explains that (in IT circles) there seems little value in tracing sor theoretical path through the schedule, if path lengths are based on activity durations that are spurious, at best.

    This, of course, brings us to the crux of the issue. Can activity durations in IT projects be reasonably estimated in advance. The author argues that most can, and that for other, less certain activities there are well-known schedule risk tools and processes.

    The author dismisses the classical IT argument (that its scope is not sufficiently understood ahead of time) as specious. While I appreciate the need to disallow this excuse to relieve the project team of any forward planning, I also recognize the immense difficulty of feigning certainty in an uncertain enterprise.And IT, like any R&D effort is, in the main, an uncertain enterprise.