The Need for a Specific Definition of "Project"
Let us remind the reader again of Dr. Bourne's observation earlier:
"...If you cannot define something precisely, you have real problems explaining what it is...
In the previous section we found that for all intents and purposes, a project is essentially a process. Further, we found that a "Process" has six key characteristics, of which one is "Embeddedness". That is "A process cannot exist in itself. It must be embedded in an organizational structure". So, it is not difficult to conclude that more frequently than not, a Project also only exists when embedded in an organizational structure.
But why do so many project managers feel that there is a need for a more specific definition of "project?
Now, we think it is fair to say that in the last several decades, with the advent of computerization, the majority of projects, in number if not in value, have been in the Information Technology and Administration sectors. And this field is still growing fast. In this dynamic situation, there is an increasing number of new and existing employed people who not only need to know what a project is, but also understand its strengths and limitations. Hence the urgent need for a sound definition of "Project" from which we can then go on to develop a correspondingly short and unambiguous definition of "Project Management".
Some people may say: "So what is the big deal? If they are comfortable working in BaU, why can they not be comfortable working on a project?" The fact is, so far as the work is concerned, the two are quite different. Indeed, this is probably the one thing, together with it consequences, that distinguishes a Project from BaU. It is not unusual for BaU people, who are much more comfortable with working in an environment of on-going Business Processes, to look askance on project management work with its unfamiliar rigors expected of them by their project managers.
So the BaU and project working environments tend to be quite different. For one thing, a BaU organization is typically set up into departments of expertise, such as purchasing, accounting, production, human resources, legal, and so on. When there is a steady flow of work coming in, it is much more effective and efficient for departments of trained people to handle this type of workload. Such work can generally be handled at a steady rate, with occasional bouts of overtime, and delivery dates are not an issue (until the customers complain too loudly!)
Under this kind if arrangement, if a project comes along, one department may start the project work and then hand it off to the next department. That department will then take it into their priority work stream according to the priorities of other work they may have, and where departmental work often takes priority over project work! Moreover, each department only takes responsibility for the work they do and not for the project as a whole. This arrangement has given rise to the nickname: "Stovepipe mentality" where work is "handed over the wall" from one department to the next, long lines of communication can exist, along with a culture of suspicion, or a dictatorial management style.[6]
For example, in building a house you would not expect the bricklayers to dig the foundations or, for that matter, expect the trench diggers to lay the bricks. That's why in practice, you call up the brick laying team when they are needed, and hope to get to the top of their priority list as soon as possible. That's not the fastest way of doing the project, but it is the best way of building a house.
The broad objective of managing such a project, i.e. project management, is to gain the benefit of both worlds - which is why we need to be quite clear on what a project is.
6. For more
examples see https://en.wikipedia.org/wiki/Stovepipe_(organisation)
|
Business Process
