This is post five of five that shares learning and insight gained during a recent consulting experience. Today’s lesson straddles the line between requirements management (generally considered the responsibility of a business analyst or solution architect) and solution delivery (generally consider the responsibility of a project or program manager).  I have straddled these practices throughout my career.

It was 2002 or 2003, I was a Software Development Manager at a large software product firm and we were making the transition from a company making a set of independent products to a company building an integrated solution suite. With the transition, we changed the way we managed requirements and our approach to solution development.  It was my first experience with a formal requirement management system and program management. The new approach made sense and since that experience I have wondered why everyone doesn’t do it that way.

Here is what I have come to understand in the 15 years since that experience, according to the PMI (The Project Management Institute), a project is;

“a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end. The end is reached when the project’s objectives have been achieved or …” PMBOK v6

Setting up a new lab is a project, and moving a team from one floor to another is a project, but in my professional opinion, providing capabilities to an organization via an IT solution should not be considered project. The business has a set of needs (requirements) to obtain capabilities. Those requirements are influenced by current technologies, policies, economics, culture and many other factors. Requirements are not static, they are fluid. They change over time and new requirements are introduced while other requirements become irrelevant. Furthermore, once an IT solution is installed, it needs to be able to evolve because; 1) business needs change and 2) technology evolves. While building the initial business solution may be considered a temporary endeavour, supporting the business solution through its life cycle is not a temporary endeavour and does not have a definite end. Thus, building and supporting a business solution should be considered a program. According to the PMI, a program is;

“a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside scope of the discrete projects in the program…” PMBOK v6

Put another way, project management is focused on the execution and completion of a single goal/objective, and bears no responsibility for the operational support and maintenance of that solution after it is developed, whereas program management is interested in the integration, coordination and optimal utilization of resources to obtain the most effective solution to achieve multiple capabilities and objectives, as well as operational support and maintenance of the solution, over a period of time. It is more about managing requirements and developing/supporting solutions through a lifecycle. It is about the initial delivery, as well as the ongoing operation and evolution of the solution as the business evolves. To that end, while there is a role for requirements management inside the scope of a project, there is also a role for requirements management within the program. The responsibilities of a program level requirements manager are similar to that of a project level requirements manager. A program level requirements manager meets with the business community to gather, refine, and update the requirements regularly. Requirements may be added, modified and dropped up at any point in time. Sometimes requirements come through scheduled meetings. Sometimes they surface via conversation. Sometimes they come from changes in the external environment. Regardless, it is the role of the requirements manager to gather the requirements and then evaluate and reprioritize the requirements according to a variety of criteria (urgency, resource availability, business value etc.), on a regular interval so that the list reflects current business priorities. Then, working in collaboration with the Program Manager and project staff, and respecting dependencies that may exist between the requirements, the program level Requirements Manager groups the requirements into bundles, projects or releases.  Only once all prerequisites have been resolved and the requirement is well understood is a requirement associated with a release. Once packaged into releases, the detailed design and analysis activities can begin, and schedules can be constructed. While it is recommended that every release require the same amount of effort, this is not a requirement. It is possible to obtain a regular rhythm by adjusting the start date, level of effort, and number of resources assigned to the task. In other cases, where the level of resources is held constant, the release content or dates shift. In order for this approach to be successful, the organization needs to recognize that:
  • Requirements are not managed within the relative isolation of a project. They are managed, across multiple projects, according to relative priority/value to the business unit today and may be reprioritized or reassigned to different releases as priorities change.
  • Projects/releases need to deliver their capability in a meaningful timeframe…. optimally 3-6 months and certainly less than 12 months. Anything much longer than 12 months is too long to respond to business’s immediate needs. Releases more frequent than every 3 months can be disruptive to the business users who need to learn the new capabilities.
For the readers that are familiar with Scrum and Kanban methodologies, they will recognize that the method identified here draws from those approaches.  I am a strong believer in the value of an iterative, continuously evolving, approach to solution development.  I’ve worked on too many projects that are still applying waterfall approaches to large IT solution development rather than opting for the more incremental and adaptive, agile approaches. So, what does it take to transition an organizational culture where is it acceptable to have huge, multi-year projects to one that is based upon an iterative series of short projects that are managed like a program? It requires a significant change in the organizational culture. The transition will not be easy.  There will be moments when team members want to regress to the old methodology, but if the leadership is persistent and patience, the benefits will come. Some of the changes that must be made include realizations such as:
  • Requirements are not static. Requirements are fluid (even when in development), but recognize that changing a requirement while it is being developed may necessitate that the requirement be bumped from the current release and rescheduled to a future release. Change is the only constant
  • It is ok to drop requirements that are no longer relevant
  • It is ok to reprioritize requirements (at any time)
  • It is ok to defer requirements where higher priorities exist
  • It is ok to defer requirements where the prerequisites/dependencies are not complete
  • It is ok to add new requirements and place them anywhere in the prioritized list of requirements
  • It is ok to change (rework, clarify) requirements
  • Requirements must be decomposed into meaningful/achievable pieces in order to flow through the pipeline
  • It is better to deliver in small, regular increments. It increases client satisfaction and provides greater opportunity to adjust to changes in business priorities
  • If a project spans more than 18 months, break it into multiple releases/increments
  • Funding should be allocated to a program that is delivering a set of capabilities to a business, not a specific project
  • The team needs to prioritize maintenance and upkeep of existing IT capabilities (i.e. upgrade a library to the next version) along with the development of new IT capabilities
And thus, the role of a program Requirement Manager, is critical to the success of the program.  It is the responsibility of the program manager to capture the priorities and desires of the business client group and package the requirements into meaningful releases of capabilities that will help the business achieve its goals and objectives, in an evolutionary way.