Jag Venugopal's Blog

June 3, 2009

The Relationship Between Project Management Processes And Software Development Lifecycle Phases

Filed under: Project Management — Jag @ 6:40 pm
Tags:
Version 1.0, 01-June-2009

 Authors of project management textbooks, and their readers sometimes confuse project management process groups with the phases of a software development lifecycle. This note attempts to clarify the relationship between these two concepts.

Project Management Process Groups

The Guide to the Project Management Body of Knowledge (PMBOK) describes five project management process groups. They are:

  • Initiating
  • Planning
  • Monitoring and Controlling
  • Executing
  • Closing

 According to PMBOK, the project management processes “… ensure the effective flow of the project through its existence“. This is contrasted with product-oriented processes, which “specify and create the project’s product“. PMBOK attempts to distinguish between the two – while the former is said to apply globally and across industry groups, the latter are said to vary by application area.

Project Phases

Project phases are a grouping of product-oriented processes, and are heavily dependent on the product lifecycle and application area. For example, a generic “waterfall” software development methodology might include the following project phases:

  • Scope
  • Design
  • Development
  • Testing
  • Deployment

 Trouble arises when users conflate the two and imply that:

  • Initiation = Scoping
  • Planning = Design
  • Executing = Development
  • Monitoring and Controlling = Project Management and Quality Assurance
  • Closing = Deployment

 At least one author has gone down this erroneous path. What is particularly embarrassing is that the author is well published and well known.

Processes at Macro and Micro Levels

Click here for a larger copy of the picture below.

 Drawing1

  The correct way to think about the relationship is that the project management processes are performed at the macro level – across the entire software project, and at the micro-level, during each phase. Some examples are provided below, for an iteratively executed project of multiple phases, with incremental delivery of desired functionality in each phase:

 Initiating: The “Develop Project Charter” process occurs once for the entire project, at the beginning of the project. Similarly, the “Identify Stakeholders” process is performed once for the entire project. However, during each phase (scope, design, …) the project charter and the business case are reviewed for applicability in light of information that might have been uncovered in the preceding phase. Furthermore, if one were to take a broader view, the initiating process at each phase would involve making a go/no-go decision based on the results of the previous phase.

 Planning: At the macro level, the planning processes answer the following questions:

  • What should our solution be? What are its components? What functional and non-functional requirements do our users expect from the system?
  • What is our prioritized list of features?
  • How many phases do we think we need?
  • How many production deployments do we need?
  • What will our resource loading look like?
  • At a high level, how much will all of this cost? Does it justify the expected return?
  • What is our QA strategy? What parts of it will we automate?
  • What is our architecture?
  • How will we communicate progress?
  • Do we need a steering committee? Who needs to be on it?
  • What are our risks? How will we handle them?

 Clearly, many of the answers will not be definitive, but will serve as best guesses for what the iterations will bring. Phase-level planning is very different – and is concerned with the deliverables due from that particular iteration. Such planning would involve clarification of requirements, creation of teams and subteams for the iteration, refining the feature list for the iteration, test cases to be written, etc. A detailed project plan with resource leveled dependencies would be created for the iteration.

 Executing: Some of the project level considerations for the executing process group are:

  • Staffing the entire project with members that will outlast individual iterations
  • Managing stakeholder expectations for overall delivery and cost
  • Identification and on-boarding of subcontractors such as staffing agencies
  • Change management (e.g. reviewing all change requests at the steering committee level)
  • Technical writing (e.g. user manual, online help, etc) and training.

These topics might be refined in each phase, but they need to be discussed beforehand. Phase or iteration level execution is concerned with creating work packages for the tasks in the plan, and assigning them to the development staff, generating status information on tasks, assessing and dealing with risk, and employee management on a day-to-day basis.

 Monitoring and Controlling: At the phase level, it is concerned with successful completion of the phase — in many iterative methodologies, a hard line can be taken against scope changes that occur within an already-executing phase. Other tasks during each phase include status reporting, quality assurance testing, and procurement (e.g. of hardware and software).

 The monitoring and controlling processes at the overall project level are concerned with the progress of the project as a whole, and whether project execution is proceeding along the lines of the plan. Considerations at the project level include the overall project progress and whether the breakdown of functionality into phases needs to be revisited. Questions that arise are whether two or more phases should be combined, or whether phases need to be added to accommodate change requests. These change request may not impact the currently executing phase, but might require the addition of an entirely new phase to accommodate it.

 Closing: Phase closeout is concerned with the completion of phase deliverables and transition to the next phase. Project closeout is concerned with such things as deployment, contract or staff termination, final documentation, contract closure and signoffs, etc.

Conclusion

Project management processes are executed at the project and phase levels, and must not be confused with the components of a software development lifecycle. Both are essential to a successful, deliberately executed project.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: