• Construction Project Management is mature and predictable, and has been (mainly informally) practiced for thousands of years now. Software Project Management is at most 50 years old in its informal and then formal form. Software Project Management is still an immature and non-standardized practice (but it is predicted to reach a comfortable level of maturity in 20 years).
• Construction Project Management is taught at school to civil engineering students (usually the course is titled “Construction Engineering and Management” or “Construction Management”, among others). Such courses are standardized all over the world. On the other hand, there is no formal education for Software Project Management (formal education is restricted to certification). Recently, however, some schools are starting to offer courses in Project Management for software students, but the courses’ contents are still not standardized (e.g. they differ from one school to the other) and they essentially reflect the teacher’s own view of Software Project Management.
• Construction Project Management is usually only practiced by those holding engineering degrees, Software Project Management can be practiced by virtually anyone, provided he possesses the necessary experience to do the job.
• Construction Project Management defines some clear and static requirements in the planning phase, which makes the waterfall methodology perfectly suitable to manage a construction project. In Software Project Management, the requirements collected from the client during the planning phase are often either unclear or incomplete, which makes the fluidity and the adaptability of an agile approach very suitable to accommodate software projects. Negative consequences may ensue Should the Project Manager elect to adopt waterfall in case of a software project, such a flood of change requests in the execution phase (potentially leading to scope inflation), which may result in a project that is behind schedule and over budget.
• Since costs in Construction Project Management are hugely offset by tangible resources (such as concrete, iron, etc…), then costs overruns may be dramatic in case of a price increase in raw materials. In Software Project Management, there are usually no tangible resources to buy, hence this problem does not exist.
• In Software Project Management, Project Managers have the flexibility of outsourcing work, consequently reducing the cost of labor, and ultimately reducing the total cost of the project. In Construction Project Management, however, outsourcing is not an option, as nearly all the resources have to be physically on-site which makes reducing the cost of labor problematic (some countries/companies overcome this inconvenience by issuing work permits to laborers from neighboring countries to work on their construction projects).
• High level politics (sometimes country politics) play a major role in Construction Project Management, low level, company or departmental politics may shape the project in Software Project Management.
• Construction Project Management thrives in a traditional organizational structure (e.g. functional or matrix organization). Software Project Management thrives in a projectized environment.
• Communication in Construction Project Management is simple and straightforward. In Software Project Management, communication is complex and plays a major role in the project: online Project Management Software is nowadays a necessity to communicate with the project team and the stakeholders.
• Conflict Management in Software Project Management is a big issue, as the Project Manager has to constantly caress the programmers’ and the designers’ egos while making sure that all personal conflicts are resolved in a timely manner to maintain a high spirit among team members (in order so sustain high productivity). On the other hand, Conflict Management in Construction Project Management is almost non-existent, this is because of the following reasons:
  • The Project Manager owns the resources, and can be much more authoritative and firm when handling conflicts (scaring potential trouble-makers) .
  • Construction workers have much less ego than programmers or designers.

  Having said that, conflicts among workers do arise occasionally, and they often take the form of a physical (not mental) conflict. Additionally, Construction and Software Project Management both suffer from high level conflicts (e.g. with stakeholders’ conflicts), although the latter is more susceptible to such conflicts.

• The types of risks differ completely between Construction and Software Project Management. Risks in the former are usually high-level, broad risks (such as new government policies affecting imports of raw materials), while risks in the latter are project-level risks such as an “unaccounted for” maternity leave for a key resource, a chosen technology that is unsuitable to build the product, etc…

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

In nearly every project, Project Managers are faced with a tough decision: Should they compromise on the schedule, the cost, or the quality (e.g. scope)? Below is an explanation of every case:

Cheap and Good

In this case the Project Manager has chosen to compromise on the schedule in favor of cost and scope, hence the project will be finished late. This is the rarest scenario, as usually a project finished behind schedule is not cheap, and ends up costing more (often much more) than its initial budget. Smart Project Managers usually do not choose “cheap and good” simply because there is a very high chance that the project will end up expensive, bad, and way behind schedule. A very late project might also get killed.

Fast and Cheap

This will result in a “cheap” project in all the meanings of the word. The Project Manager opts to favor time and cost at the expense of the scope. This means that the end product/service will not be delivered according to the original scope: either the quality will be greatly reduced or some planned (key) features will not make it in the released version (in case of a software project). Needless to say, this is the most common scenario across the board, and is the favorite for both the Project Manager and the stakeholders:

• The Project Manager will be regarded as someone who “gets the job done”.
• The project stakeholders will be satisfied that they have a product/service delivered on time, albeit missing some features.

Negative effects for internal projects are usually minimal, however, for projects delivering a product or services to an end client, then the reputation of the company might suffer on the long term. Having said that, it is amazing to see that a lot of mega-companies follow this same strategy, and get away with it (the famous “release now, patch later” mentality). These companies are still growing and expanding.

Fast and Good

This is the preferred choice of Project Managers in case of construction projects, where adding more resources makes sense and can greatly accelerate the speed of the project, but, of course, at an increased, condensed cost. In case of software projects, this approach is not practical, as adding more resources increases the communication channels, ultimately reducing the velocity of the project (In general, Project Managers are advised not to take this approach for software projects).

Sadly, in almost all cases, scope (and consequently quality) is the first constraint targeted by Project Managers. The reason for that is that scope is traditionally non-measurable, as opposed to both the schedule and the cost. Stakeholders are more open to accept a reduction in the quality or features in the end product or service, than an increased cost or a prolonged schedule. This is the reason why so many products out there don’t turn out as people initially expected.

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.