Program Management – When should a project become a program?

Projects, on an individual basis, exist throughout any organization. They can be part of an overall product deliverable, an internal initiative, a process change effort or a tiger team working on R & D.

Whenever any project is instantiated, it has roughly the same constituent pieces: a project manager, a team, a set of stakeholders and most likely a project sponsor. The term ‘project’ is used rather liberally in all circles nowadays, including modern lexicon. We often here of neighbors or colleagues talk about their home ‘projects’, such as painting a room or redecorating a section of their house. Clearly, projects themselves have become a staple fixture within personal and professional arenas alike.

But this begs the question: when does it make sense to enact a program? What aspects of an overall organizational goal necessitate the need for a larger, broad-based program to be created and maintained? Under what circumstances is a program warranted and what precisely is the difference between running multiple, simultaneous projects and a single program?

In most cases, one fundamental question needs to be asked when determining if a program is necessary: are the multiple projects being worked on inter-related in a tangible way and if so, do they have common milestones and inter-dependencies?

As a project manager, when managing several projects and trying to determine if a ‘program’ is needed, a good frame of reference is to consider real world examples and cases where programs were enacted by other organizations. For example, consider something like the Microsoft XBox360 console.

The console itself, when completed, is a singular unit for purchase. Customers will buy the console as a whole (with potentially some additional peripherals) and take it home. But if one examines the console itself, how many individual pieces and components does it contain? As an exercise, we will itemize them:

  • Motherboard and CPU
  • Hard drive or memory card
  • Graphics Card
  • Ancillary access ports
  • Game controllers
  • Operating system
  • Ethernet capability

Now as many might surmise, it is likely not the case that all of these components are being worked on by the exact same people or even in the same location. It is also possible that some of these constituent components are ‘farmed out’ to third-party vendors. Or some aspect of those components is farmed out.

In any sense, what is clear is that in order to produce the end product, there are several pieces that need to be created and maintained and that all of these pieces are part of the whole. And being that the release cycle of the console necessitates the need for the pieces to be delivered in the same timeframe, this is an obvious example of the need for a program.

In a similar sense, as a project manager, the best way to determine whether a program is warranted or not in your particular case is to look at all the individual pieces and dependencies. Determine how they inter-relate and get a gauge of who is working on what and where. As a rule of thumb, as the complexity of the deliverable increases, the need for a program (or even multiple programs) goes up.

The choice to create a program will often become self-evident as the project manager begins to take ownership of various projects. Once a determination is made of the overall set of projects and how they inter-relate, a more informed decision can be made.


Project Risk Management – Tools and Techniques

Every project, regardless of scope or complexity, is going to have some inherent risks. The type, number and severity of the risks will vary depending on a variety of factors, such as the project’s overall size, its related constituent pieces, the number of individuals on the project, and so forth.

But how does the project manager effectively catalog these risks? How are they adequately itemized and made part of the overall project management plan?

Any sort of risk assessment, regardless of the situation, is always a combination of both art and science, coupled with the individual’s own personal experience and knowledge. Because risks are, in and of themselves, intangibles, cataloging them can be somewhat daunting.

The PMBOK (Project Management Body of Knowledge) has an entire chapter dedicated to the concept of risk management. In some cases, seasoned professionals are actually brought in to provide their consulting expertise to make sure that all project risks are effectively itemized. But in most cases, it falls onto the shoulders of the project manager to be able to make that assessment. With that being said, how should the project manager proceed?

If one follows the PMBOK’s suggestions, it is important to create a task list. The PMBOK suggests the following tasks to be performed in sequence:

  1. Define the Risk Management Process (And make this part of the overall project plan)
  2. Identify Risks
  3. Perform a Quantitative Risk Assessment
  4. Perform a Qualitative Risk Assessment
  5. Create a Risk Response Plan
  6. Monitor Risks during the life-cycle of the Project

As some might indicate, the most difficult step in the process itself is to identify the risks themselves. There are some rules of thumb that one can follow when it comes to assessing the risks themselves. A step approach could be something like so:

  • Examine the plan and scope of the project; identify short-term tasks and assess the risk of each one individually
  • Examine the project as a whole; if there are dependencies (internal and external), assess the risk of those dependencies and catalog them
  • Determine the risk of the project not succeeding; what are the financial risks that one must be aware of
  • Assess the budget of the project (if any); determine areas that may induce risk pertaining to budgeting (i.e. cost of contractors, cost of tangibles, etc)
  • Determine any external risk factors, such as competitors or potential changes in market sentiment in regards to the project and its deliverables

Once the risks themselves have been itemized, there are two different ways of assessing the risks: quantitative and qualitative risk analysis. Those are defined as follows:

Qualitative Risk Analysis – This is the more subjective of the two. It relies very much on the experience of the project manager in being able to effectively gauge the risks themselves. A good rule of thumb when performing this type of analysis is to ask specific hypothetical ‘what if’ type questions. A few examples might be:

  • What if engineer ‘A’ leaves the project or is reassigned?
  • Have the requirements been properly itemized? And what if they haven’t?
  • What if the budget is adjusted half-way through the project’s implementation?
  • What if the learning curve for new technology is steeper than anticipated?
  • What if a dependent project runs into trouble? How will that affect the primary project?

Quantitative Risk Analysis – This uses more tangible or ‘hard’ assessment types, such as percentages, probabilities and numbers to demonstrate some of the risks that could cause project problems. In many cases, having this type of assessment available is very important to certain senior management types that require more in the form of numerical values as opposed to more subjective measures. Things like schedule ranges, cost budget ranges, and probability analysis (best or worst case scenario calculations) would fall into this scope.

When it comes to risks, experience of the project manager is the most valuable asset. So if you are a newbie, it might be a good idea to discuss risk analysis with more seasoned and experience project manager’s to gain their insight, especially if they have more working knowledge of a particular area. Also, when you become more familiar with risk analysis, creating a checklist that you can reference for future projects is a very good reusable resource that a project manager can leverage. Combining your list with those of other project managers will also allow you to have a more complete assessment of all the potential risks and risk types that you need to be cognizant of when monitoring your project.

The following graphic is a good frame of reference when it comes to the risk analysis cycle:

It demonstrates the ‘cyclical’ aspect of the overall risk management process. So ensure that you utilize it for reference during the project life-cycle to ensure you are effectively monitoring the project risks.