Project Management

Project managers need to understand lifecycle work

Tom Mochal explains the difference between project management and the project lifecycle.

Some people are confused on the difference between project management and the project lifecycle. It takes both types of work to complete a project successfully. The general difference is that project management is used to define, plan, control, monitor and close the project. The work associated with actually building the project deliverables is accomplished through work that is referred to as the "lifecycle." Project management is used to build the schedule, but the vast majority of the work in the schedule is the lifecycle work associated with building the project deliverables.

Projects can be managed using a common set of project management processes. In fact, one of the valuable things about having a common project management methodology in your organization is that the same processes can be used on all projects.

Tips in your inbox
Looking for expert IT project management? Get the help you need from TechRepublic's free Project Management newsletter, delivered each Wednesday.
Automatically sign up today!

What makes a project unique are the deliverables that each project builds. For example, building a bridge is a different type of project than building an IT solution, or building a new consumer product. The lifecycle describes the activities used to build the deliverables and is generally unique for each project.

Even though all projects are unique, there are still common lifecycle models that can be used to build deliverables in similar ways. The generic "waterfall" is an example of a lifecycle model. In a waterfall project, you start off understanding the requirement of the solution, designing a solution, building and testing a solution and then implementing the solution. Each of these major areas of focus is called a phase (Analysis Phase, Design Phase, Construct Phase, etc.) What could be easier? The classic waterfall approach is the lifecycle model you would probably end up with if you knew nothing about methodology and just had to build a project workplan from scratch.

Although the waterfall model can be applied to all projects, other lifecycle models might be more efficient and effective based on the characteristics of the project. For instance, if you're installing a software package, you can utilize a specific lifecycle model for package implementation that is light on the design and construct phases. Likewise, if you're conducting a research and development project, you can use a specific R&D lifecycle model that takes into account that the work might be thrown away when you're done. If you're building a marketing campaign, there's a general lifecycle model that can describe the activities to be successful. Building a house is certainly complex, but a basic home-building lifecycle model will probably cover 90% of the work on almost all home construction.

I've been in many organizations that say they have a good project management process, but the process actually describes the lifecycle, or execution, portion of the project. If your project does not include both the lifecycle and the project management activities, you'll be less likely to be successful than if your schedule includes both important components.

14 comments
montsi
montsi

Hi guys, Please tell me How does project scope control apply in the execution phase of the project lifecycle only or is it influenced from elsewhere?

Mr Flibble
Mr Flibble

The "lifecycle" in question is covered in general by the Systems Engineering Lifecycle". Project Management has it's own lifecycle which is applied to whichever "piece" of the systems engineering lifecycle is within the scope of the project. Think of a "design" project or a "decommissioning" project. These only cover a portion of the systems engineering life cycle but would fully exercise the project life cycle. I my experience the inability of people to clearly differentiate between the two lifecycle models is the root cause of much of the wooly thinking and confusion around project work. A key indicator is to look for instances where systems engineering lifecycle elements are included in the definition of the project lifecycle. Before anyone says "But my projects are different and the systems engineering lifecycle does not fit my industry/technology/service" please check your understanding of the systems engineeering life cycle. It is universally applicable. If you havn't grasped that you don't understand the concept and principles fully. Project Management manages the context. Systems Engineering manages the content.

mcd3000
mcd3000

In our consulting firm, we use the ISO12207 framework to conceptually describe the overall software processes. ISO defines 14 macro-processes for software development, plus a few "organizational processes" such as project management. For project magagement we use the PMI PMBOK Guide, which includes 44 processes and a bunch of outputs for initiating, planning, monitoring & controlling, and closng a project. By splitting PM process away from all the actual delivery work (eg. BA, QA, architecture, development, user experience, etc.), and tailoring industry standards we gained a lot of understanding: 1) We understand the importance of having a formal PM - especially in the sales phase where most of the damage to a project usually happens (due to poor estimation and over-promises). 2) We learned that there is really one master process from which subsets can be applied to handle any situation. The PM Master Process and the SDLC Master Process. (Note: there are a few exceptions, where the lifecycle is dramatically different - eg. ERP solutions. I think this idea was pointed out already in this thread.) 3) We understand that we need different views of our lifecycle depending on the project type (customer, industry, technology, size, etc.) 4) We understand which job roles are needed for which types of projects. (Before, PM and BA processes were all combined into a single "lifecycle" document. This had the undesireable effect of us creating PM/BA job specifications and hiring folks who are "jack of all trades, master of none.") 5) Our customers recognize the names of the documents they receive, since we're using standards now. For example, there used to be a lot of confusion around whether the scope should be in the project charter, project plan, or functional specification. Depending on who was planning the project, you'd get a different document (and never in the same format as the previous project). 6) When things go wrong - whether identified during a project, or after it's closed - we can always point to the processes that failed. This allows us to manage risk much better and to improve over time.

Tony Hopkinson
Tony Hopkinson

is people picking the life cycle, then trying to hammer the project into it. It should be the other way round, look at the project pick the best lifecycle model. Classic waterfall is a prime example, it rarely fits a project in the real world, most of those are better with iterative. The only life cycle I can think of where PM activities aren't explicitly defined as part of it is RAD, which explains why it was an abysmal failure in practice. Agile and spiral are the two I use most often. Defined deliverables and review points need to be adhered too whatever your lifecycle otherwise it's not being managed. The trick with any IT project is to discover as early as possible, you are going wrong somewhere.

derek.edmonds
derek.edmonds

I would be interested in your views on how defined project lifecycles can be applied to the less definite "business initiatives", normally classed/disguised as BAU. Unless there?s a distinctive definition of a project, which can cover all aspects of change within an organisation then the BAU card will and can be used.

holger.heuss
holger.heuss

Tony, for me two points are important: 1. The organisation must provide multiple lifecycles to the PM community. Problem with that is the workload associated with this (and the expertise required to establish, implement and maintain) 2. PM should be able to work in different lifecycles on the same project if necessary, e.g. waterfall to satisfy requirements like finance etc and iterative for the core of the project. Education and expertise are possible problems... I tend to disagree with your statement about existance of PM activities in different lifecycles... IF they are included they cover usually the basics in administration and planning but are not sufficient to do a good job as a PM.

dbabcock
dbabcock

Derek, I, too, don't understand the definition of BAU and it's relationship to business initiatives. Can you provide a cogent definition behind DAU. THANKS! Dave

holger.heuss
holger.heuss

Hi Derek, project is defined as finishing at some point (most do that but late;-) whereas BAU is an ongoing exercise. If you are not working in a project-only organisation (professional services, consultancy, etc) than project managers have to cater for this by allowing for a certain percentage of time which their team members are not available for project work - this gets very often forgotten. I have also experienced clients where they forced everything BAU into projects, I would advise against this as it takes away the benefits of "project" work such as the timeliness of delivery. hope that helps Holger

Tony Hopkinson
Tony Hopkinson

the life cycle is a frame work in which the PM is active, there is of course a lot more to it than simply chairing a review meeting. The big thing I like out of a PM is managing expectations. Doesn't matter how technically competent my design or my implementation is, if that's gone wrong it will look crap whatever I do.

bkimmell
bkimmell

Hi Holger: Your comment is very accurate. What I would like to know is how do you determine the "certain percentage" mentioned in your reply. How is it derived? As an example, when bidding on a project what percentage should be added on the schedule to compensate for project members unavailable for project work. Thanks BAKimmell

sjsullivan
sjsullivan

Can you define/clarify your use of the acronym 'BAU' ? We have occassionally used the phrase to mean 'business as usual'. But, you refer to it in your reply as "a BAU", implying that it is something quite specific.

bill
bill

I usually try and talk to the In Life Support people (who are usually the ones who are critical to delivery, but have the least time) and offer to backfill those I need with outside resource for the period of project time. This has some interesting effects: o enables me to have a legitimate call on their time o lets their manager know if they have a single source of critical information o BAU processes seem to be better documented for handover to contractor or o As often happens the BAU resource will give up their time without having to bring in extra heads as they don?t want to have to handover to outsiders That way BAU manager has to ensure that his work as well as the project work is covered. I hope this helps too Bill

holger.heuss
holger.heuss

Sorry but I can only come up with the typical consultant answer: It depends ;-) Utilization models I am working with have factors such as public holidays (differences by country, regions, religion, etc.), holidays (contracts), illness (I assume 1 week/year), administration (time for filling out time sheets), education (depends on company policy) attached to it. You will find out how little time people really work... And then you take off time for BAU... again higly dependable on the role (e.g. someone works in a customer call centre, you might get generic data) hope that helps Holger

holger.heuss
holger.heuss

Sorry but this was based on my poor usage of the English language - humble apologies!

Editor's Picks