Project Management vs. Practical Management (Part 2)

The definition of a project and how that informs use of best practices.

Last time I wrote about the project lifecycle and how different real-life (practical) management differs from the PMI textbook definition (especially with regard to team development). This time I want to go even farther back and discuss the definition of a project and how it affects planning (not just for projects but for any management really).

The Project Management Book of Knowledge (PMBOK) defines a project as "a temporary endeavor undertaken to create a unique product, service, or result".

Previously when I taught courses on project management (regardless of the level or the course content), I would hammer this point home and focus on the two highlighted keywords "temporary" and "unique". Let's dive into each of these terms and how they relate to not just project management but to management practices in general.

Temporary:

By definition, this obviously applies to a fixed period of time but what qualifies? Two weeks (Agile people)? Six months? Two years? Every person and organization will have their opinions on this and the bottom-line.... it doesn't matter. The key is to define the timeline for that "particular" project as early as possible. Do you have to be precise? Sure but only because someone is going to make you be but if you can be less precise (e.g. "its roughly a 3 month project" vs. "you have 12 weeks to complete") this will certainly aid in your (re)planning (as noted before, the lifecycle doesn't exactly occur as we would like).

My biggest issue with the term temporary is that it tends to breakdown when you look at higher levels such as program and portfolio management and also that project management concepts can't be applied to everyday management because those are not always "temporary". Good program and portfolio managers understand that the temporary nature of projects by extension makes their work "temporary" even if those timelines are little less defined and nebulous. This affects how projects interact and involve each other and the planning for those programs and portfolios. Operationally, project management best practices can be applied by thinking of your work in self-defined (temporary) time periods. For instance, when strategic planning or budgeting for the next year, you can use that as your "temporary" time period and use best practices to determine your resource needs (forming), activities that will be done (storming and performing), processes that will need to be changed (norming), and even if some aspects are shutdown or sunsetted (adjourning).

Unique:

I always find it good to remember that project management evolved from construction management. If you think of building a house, that produces a "unique" product -- a house. However, if you have ever seen a whole neighborhood of cookie cutter houses go up (like where I live), you start to think; there isn't a whole lot "unique" between those. I'm sure some construction PM will disagree with that but it was just to present a picture so bear with me. My point is that even in the industry which spawned the best practices, sometimes its hard to define the "uniqueness" of a project but you must try as that often is the difference between success or failure. If you treat all of the work as the same, you run the risk of missing those key points of difference and the effects can be disastrous.

Uniqueness is also a problem when it comes to other applications of project management. For instance in software development, if you are working on new features for an existing product, is that "unique" enough. In Agile development, often new feature work is mixed in with bug fixes and other maintenance items. Does that qualify as unique? Are you more or less stringent on your application of best practices because of this? Do you modify what you do?

Finally, this term also makes it sound not applicable to operational work because its not unique but often repetitive and structured. What if you looked at it from a different viewpoint? In the past I have held what I call the "corporate fireman" role where basically I was sent in where a team (project or operational) was in trouble and needed help. The first thing I would then do is banish phrases like "that's how we do it" and "how it's always been done". My response to those stances is that if what you were doing was working, I wouldn't be there. By taking that stance, I was already looking to produce a new (unique) result and thus could apply project management best practices to that end.

So what actions can you take going forward:

• If you are project manager, make sure you truly understand the temporary and unique nature of your project going in. It will pay dividends in the long run. Don't be afraid to ask those questions because those who defined the project might not have.

• For all managers, look around your organization. Are there areas other than projects that could make use of PM best practices? Can you define their temporary and unique nature? If so, you can definitely make use. Give it a shot, you might be surprised!