When many of us think of project management we think of two industries: Information Technology and Construction.  Actually, more people work on IT projects than on any other category of project. In fact, if you were to conduct a statistical investigation of who is doing what on projects implemented throughout the world, you would likely find that more people are working on IT projects than on all other types combined but that is definitely changing as PM is becoming a more recognized discipline.  More and more things are being called ‘projects’ and need project management oversight.

Many who have studied project management over the years have emphasized the universality of project issues encountered by project workers, regardless of the specific nature of the projects being undertaken. After all, a schedule is a schedule, whether it has been created for a construction project, an FDA approval effort, or an IT implementation. Given that, it’s possible to learn the ins and outs of different project management scheduling tools like Seavus’ Project Viewer and other tools without worrying about the specific context in which the schedule occurs. Similar arguments can be made about budget and resource allocation tools.  They work for one, they generally work for all.

It’s definitely interesting how the experiences of people working on different types of projects are so similar. Through the reading I have done, I’ve found that construction project managers and software project managers seem to have many common experiences to share. Both groups often use borrowed resources – as in a matrix environment – so they face the common situation where project managers do not control the resources with which they must work. And they both operate in environments where there is a tendency for project scope to grow as the project is carried out.  Meaning scope management and scope creep is always a top concern.

It seems that now we have begun to turn our attention to the special circumstances governing project work in different business areas. In particular, we now recognize that knowledge-based projects face a different set of challenges than the challenges that traditional projects in the construction and defense industries encounter. For example, knowledge-based projects are heavily oriented toward dealing with intangibles. Knowledge itself is ephemeral and ever changing. Because knowledge is abstract, it is hard to capture and articulate customer needs and to convert these into concrete requirements. These are the types of issues that workers on knowledge-based projects must contend with day by day.  I consider requirements to be the lifeblood of the project, however, they are sometimes so incredibly hard to accurately nail down that the project can spin out of control later on if we find that we did not capture detailed enough or accurate enough requirements.

Call for responses