4squareviews

When I sat down to do this post, I realized that a) this process is so crucial to the success of a project and b) there are so many tools & techniques in this process , that I can’t do it justice in one post.   I am going to start with an introduction to the different types of requirements.

Types of requirements

1. Business requirements–these high-level requirements a) help the project align with the strategic objectives of the company, as well as b) assuring that the business need, i.e., the reason why the project has been undertaken, will be filled by the product, service or result that the project will create.   The source of these requirements can be found in the project charter and/or business case document.
2. Stakeholder requirements–These are requirements from a particular stakeholder or group of stakeholders.   These requirements are found by engaging with the stakeholders.
3. Solution requirements–What are the particular features, functions, and characteristics of the product, service or result that will meet the business and stakeholder requirements listed above.   Now we are getting into the details of what the product will turn out to be, and for that reason the source of these requirements will be subject matter experts.   There are two sub-types of solution requirements:
   • Functional requirements–what are the data, actions, or processes that the product should execute?
   • Non-functional requirements–these supplement functional requirements and describes the environmental conditions or qualities required for the product to be effective.   How reliable is the product?   How easy is it to use?   What technical or other support will it require for continued use?
4. Transition and readiness requirements–these are the temporary capabilities, such as a training requirements, that will need to be in place to transition to using the product.
5. Project requirements–these deal not with the scope of the product, as the categories above do, but with the scope of the project itself.    For example, what are the constraints on the budget and schedule?   (The quality requirements are a constraint that are dealt with in the category below.)
6. Quality requirements–scope is a constraint that deals with the completeness of the work, quality is a constraint that deals with the correctness of the work.    What are the conditions or criteria needed to validate the end result of the project?   Are there tests that need to be performed?   What is the inspection procedure going to consist of?   Is it important to get this spelled out at the beginning of the project so that the process of validation of the end result is a) objective and b) understood by the customer or the sponsor of the project.

So, these requirements range from the high-level (category 1) to the specific (category 3 and 4); stakeholder requirements (category 2) can be either high-level or specific.    The requirements can be related to either the scope of the product (categories 1-4) or the scope of the project (5-6).

Now that we have categorized what requirements may be considered, the next post will start to go through the tools & techniques that will collect, organize, prioritize, and finally select the requirements that will form the shape of the scope of the product and the project itself.

Filed under: Uncategorized | Leave a comment »

The first process in the Scope knowledge area, Plan Scope Management, was essentially a place where all the other processes for scope management were detailed, including this first one, Collect Requirements.

The requirements are the conditions or capabilities that the product, which is being produced as a result of the project, are supposed to contain.    These requirements are  the scope of the product; it is distinguished from the scope of the project, which is the work required during the project to produce that product as an end result.

Where do these requirements come from?   They can be specified in the project charter (see 5.2.1.1 below), they can come from business documents like the business case (see 5.2.1.4 below), from agreements (contracts) with vendors or business partners (see 5.2.1.5 below), or from stakeholders.   This post will cover these various inputs into the process of collecting and analyzing these various potential requirements,

5.2.1  Collect Requirements:  Inputs

5.2.1.1 Project Charter

The project charter is the output of process 4.1 Create Project Charter.   The project charter is essentially the “seed” of the project, because it contains a lot of high-level information on the project including any high-level requirements the sponsor wants to include as part of that charter.   This is probably the first place to look for such requirements if you are a project manager.

5.2.1.2  Project Management Plan

The components of the project management plan that are used as inputs for this process are:

• Scope Management Plan–this is the output of process 5.1 Plan Scope Management.   In particular, the scope management plan will show how this process, 5.2 Collect Requirements, needs to be done.
• Requirements Management Plan–the Project Management Plan contains management plans from each knowledge area, like the Scope Management Plan mentioned above, and it also contains some supplemental management plans like this one designed specifically on how to handle requirements.   Given that the subject of this process is requirements, it is easy to see why this management plan is an input.   It is also an output of process 5.1 Plan Scope Management
• Stakeholder Engagement Plan–this is an output of process 13.2 Plan Stakeholder Engagement.    You will need to get many of the requirements from stakeholders to supplement the ones you find in the project charter and the business case, and the Stakeholder Engagement Plan will give you information on who the stakeholders are and what their current level of engagement is with respect to the project.

5.2.1.3 Project Documents

Here are some project documents which may be considered as inputs for this process.

• Assumption log–high-level strategic and operational assumptions and constraints are normally identified in the business case (see 5.2.1.4 below) and will flow into the project charter (see 5.2.1.1 above).   These high-level assumptions are then put into the assumption log, which will later also include lower-level assumptions such as technical specifications, budget and schedule estimates, risks, etc. that will be developed later on in the planning process.
• Lessons learned register–(output of process 4.4 Manage Project Knowledge)the specific area that this register can provide information on is techniques for effective collection of requirements, particularly for projects that are using iterative or adaptive (agile) product development methodology that develop the scope on a cyclical or ongoing periodic basis.
• Stakeholder register–(output of 13.1 Identify Stakeholders) contains information on stakeholders so you can identify those who can provide information on the requirements.   It also contains information on the stakeholder’s expectations and level of engagement with the project which will help you when engaging them regarding these requirements.

5.2.1.4  Business Documents

In particular, the business case, which ties together the a) purpose or objective of the project, b) the business need for the project (why is the project being done, i.e., what need does it fulfill), and c) the strategic alignment of the project (how will it align with the business strategies of the organization doing the project).   This can be done by the sponsor or by a business analyst.

5.2.1.5 Agreements

Agreements with business partners can contain project and product requirements.    (There are also agreements with vendors, but these will enter the picture later on in the planning process.)

5.2.1.6  Enterprise Environmental Factors

Several of these are listed in the PMBOK Guide, but the most important are the organization’s culture, which will determine many requirements on how the project is done (the scope of the project), and marketplace conditions, which will determine many requirements of the product.

5.2.1.7 Organizational Process Assets

The OPAs that can influence the Collect Requirements process include:

• Policies and procedures–this will go into the Scope Management Plan which will outline the process by which the company will do the processes in the Scope knowledge area, including how requirements should be collected and analyzed, which is the subject of this particular process 5.2 Collect Requirements.
• Historical information and lessons learned repository from previous projects–this will contain information not only on how requirements were collected from previous projects, but will also inform the assumptions log which will be helpful in analyzing those requirements.

Now that you have the requirements you have collected from various sources–from the project charter, business case, stakeholders, and project documents such as the assumptions log and the lessons learned register, it is now time to analyze them.   That is the subject of the next post…

Filed under: Uncategorized | Leave a comment »

There are two outputs for this process:   the Scope Management Plan and the Requirements Management Plan.   These plans outline the all the other processes in the scope knowledge area.

5.1.3 Plan Scope Management:  Outputs

This plan shows how the scope will be defined and developed in the Executing process group, and how it will be monitored, controlled and validated in the Monitoring and Controlling process group.

The components of the scope management plan include:

• The process for preparing a project scope statement, as part of Process 5.3 Define Scope.
• The process for enabling the creation of the Work Breakdown Structure (WBS) from the project scope statement, as part of Process 5.4 Create WBS.
• The process for approving and maintaining the scope baseline, as parts of Process 5.6 Control Scope.
• The process for formally accepting the completed project deliverables as part of Process 5.5 Validate Scope.

5.1.4 Requirements Management Plan

This plan shows how the project requirements and the product requirements will be analyzed, documented and managed.    This is sometimes called the “Business Analysis Plan” when it is a document created by business analysts.

The components of the requirement plan include:

• The process of planning requirements activities
• The process of configuration management, which tracks changes made in the requirements during the course of the project.
• The process of prioritizing requirements
• Metrics used in the process of showing successful completion of requirements
• Traceability of requirements, so that team members can be identified to be responsible for certain requirements, and subject matter experts can be consulted when decisions have to made concerning those requirements.

All of these requirements are part of the Process 5.2 Collect Requirements.

As you can see from reviewing the above, essentially the output of this Process 5.1 are the guidelines of how to do the processes in all of the other Processes 5.2 through 5.6.

Next process is Process 5.2 Collect Requirements:  that is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

This post will discuss the tools and techniques involved in the Plan Scope Management Process.   When you have a decision-making process, like you do in most planning processes like this one, the key tools & techniques are going to be

• expert judgment (these are the people that will help you make decisions)
• data analysis (these are the techniques that will help you make the decisions)
• meetings (this is the forum in which you will make the decisions)

This process is like others, and has these three tools & techniques.   Let’s take a look in a little more detail:

5.1.2 Plan Scope Management:  Tools & Techniques

5.1.2.1  Expert judgment

In particular, those individuals that have experience on previous similar projects should be consulted in creating the scope management plan.

5.1.2.2  Data analysis

A particular data analysis technique used in this process is alternatives.   There are many requirements that will be discussed; how will they be achieved?   There may be more than one way to achieve a certain requirement, and after brainstorming for alternatives, then the decision becomes which of the alternatives the project will pursue.   That is where alternatives analysis comes in.

5.1.2.3 Meetings

Of course, any decision-making process requires a meeting of the minds because the problem is too big for any one person and their individual perspective to solve.   The people that should be attending, besides the project team of course, are the sponsor and selected stakeholders, and any other individuals who are responsible for scope management processes in the organization.

These are the tools and techniques used in this process; the next post will cover the outputs, the main one of course being the Scope Management Plan.

Filed under: Uncategorized | 1 Comment »

Before I go into the inputs for this first process in the Scope knowledge area, let me go over some key concepts that are described on p. 131-133

Product scope vs. project scope

The product scope refers to the features and functions that characterize a product, service, or a result, whereas the project scope refers to the work performed to deliver that product, service, or result.

Life cycle–predictive and adaptive

The life cycle is the approach you take when planning and managing the scope of the project. A traditional or predictive life cycle is, as the name implies, one where the scope is defined at the beginning of the project.   In an adaptive or agile cycle, the overall scope is decomposed into a prioritized set of requirements (the product scope) and work to be performed (the project scope) called the product backlog .   At the beginning of each iteration, the team will work to determine how many of the highest-priority remaining items on the product backlog can be determined during the next iteration.

Another important difference between the predictive and the adaptive life cycle is the  process of Validate Scope.   This is the process where the customer is shown the deliverables and formally signs off and approves them.   In a predictive life cycle, this is done at the end of the project when the final deliverable is completed, whereas in an adaptive life cycle, it is done at the end of each iteration.

Requirements

Project management is increasingly focused nowadays on the management of stakeholder requirements.   Business analysis is the role that comes up with business requirements, and although a project manager may not have to create documents such as the business case, it is important than the project manager understand them.   Why?  Because if conditions change such that the assumptions embedded in the business case are no longer valid, the justification for the project’s continuance may no longer exist.

Now let’s talk about inputs to this process

5.1.1 Plan Scope Management:  Inputs

5.1.1.1  Project Charter

The parts of the project charter that are relevant to scope management are:

• Project purpose
• High-level project description
• Assumptions
• Constraints (budget, schedule, or others)
• High-level requirements

5.1.1.2 Project Management Plan

Components of the project management plan that are relevant include the project life cycle description and development approach (predictive, incremental, or adaptive/agile), as well as the quality management plan.   The scope covers the completeness of the work, but quality covers the correctness of the work.

5.1.1.3 Enterprise Environmental Factors

An organization’s culture and infrastructure are among the factors that can affect the management of scope.

5.1.1.4 Organizational Process Assets

An organization’s policies and procedures are important for any management plan, and  historical information and lessons learned repositories may help guide the development of the scope of the project if it is similar to one done in the past.

The next post will cover the tools & techniques of this process.

Filed under: Uncategorized | 2 Comments »

This process is the final process you will do as a project manager on a project.   This post will cover the outputs of the process.

4.7.3 Close Project or Phase:  Outputs

4.7.3.1 Project Documents Updates

The most important project document to be updated will be the lessons learned register, which may include information on:

• Benefits management (making sure benefits of project continue after long after the project is done)
• Accuracy of the business case (was the business need fulfilled by the project, did this project contribute to the strategic objectives of the organization)
• Risk and issue management (including risk register and issue log)
• Stakeholder engagement (including stakeholder register)

4.7.3.2 Final Product, Service, or Result Transition

The product, service, or result created by the project will be handed over or transitioned to a different group or organization if it is an external project, but it will be handed over to the organization itself in the case of an internal project.

4.7.3.3  Final Report

This is a report on the success of the project based on the success criteria set forth in the project charter, which may be based on  scope, schedule, cost and quality objectives.

4.7.3.4  Organizational Process Asset Updates

• Project documents–the entire project management plan may be used to update the procedures, processes and guidelines of the organization
• Lessons learned repository–the lessons learned register for the project will be added to the organization-wide document called the lessons learned respository.
• Project closure documents–customer acceptance document from the Validate Scope process will be transferred to the document database of the organization
• Operational and support documents–documents which help to maintain, operate, and support the product or service delivered by the project.

This is it for the Integration Management knowledge area!   The next post will start the Scope Management knowledge area with the first process, 5.1 Plan Scope Management.

Filed under: Uncategorized | Leave a comment »

This process, although it is the final process, is like any other process where there is decision making, in that the key tools are going to be expert judgment, data analysis, and meetings, just like in other processes in this knowledge area such as 4.2 Develop Project Management Plan, 4.5 Monitor and Control Project Work, or 4.6 Perform Integrated Change Control.

However, the purpose will be different–essentially the work should be done by this point, and the customer should have formally accepted the final product of the project in the process 5.5 Validate Scope.   The main work here is close the project formally within the organization.

Here are the tools & techniques of this process.

4.7.2 Close Project or Phase:  Tools & Techniques

4.7.2.1  Expert Judgment

Experts are needed especially when it comes to matters having to do with legal matters or with internal requirements when closing a project.

4.7.2.2  Data analysis

This is used to create a “scorecard” of how the project did with regards to the schedule and budget.

4.7.2.3  Meetings

The project team members and other key stakeholders are the ones who attend these meetings, which are used to do the following:

• Confirm that deliverables have been formally accepted
• Validate that success criteria have been met
• Formalize completion of contracts
• Evaluate satisfaction of stakeholders
• Gather lessons learned
• Transfer knowledge and information from the project
• Celebrate!

The outputs of this final process are covered in the next post.

Filed under: Uncategorized | Leave a comment »

This process is the final process you will do as a project manager on a project.   If it is the last process, what is the next to last process.   That is process 5.5 Validate Scope, where you take your final deliverable and show it to the customer for final, formal appearance.  If and only if that deliverable is accepted, does the project enter the “close project”  process.

Let’s go over the numerous inputs to this process.

4.7.1  Close Project or Phase:  Inputs

4.7.1.1  Project Charter

This should contain the project success criteria, and who signs off on the project (usually the project sponsor).

4.7.1.2  Project Management Plan

The project work was done based on the project management plan, which is also an input to the process.

4.7.1.3 Project Documents

There are many project documents that are inputs to this process.   The entire list is in the PMBOK Guide, but the most important are:

• Quality control measurements–this demonstrates compliance with the quality requirements.
• Requirements documentation–used to demonstrate compliance with the project scope.

4.7.1.4  Accepted Deliverables

These are the outputs of the process 5.5 Validate Scope.   It is important that the deliverables are accepted formally, i.e, in writing, in order to avoid any possibility for miscommunication.

4.7.1.5  Business documents

These are inputs to the process 4.1 Develop Project Charter.

• Business case–justifies the project by documenting the business need and the cost benefit analysis associated with the project.
• Benefits management plan–ensures that the benefits created by the project will continue beyond the lifetime of that project.

4.7.1.6 Agreements

These contracts with other companies contains the formal closure of procurements that were created by those companies and used on the project.

4.7.1.7  Procurement Documentation

This documentation is used, together with the contracts (= agreements) themselves, to demonstrate that all procurements are properly closed.

4.7.1.8  Organizational Process Assets

Here are some of the organization standards, processes and procedures that may be inputs to this process.

• Project closure guidelines or requirements
• Configuration management knowledge base (contains baselines and all versions of organizational standards and policies)

The next post will cover the tools & techniques involved in this process.

Filed under: Uncategorized | Leave a comment »

This process is one of the most important project management processes because it is the management of change on the project, and doing this skillfully can make or break a project.    The last post talked about the tools & techniques–this post is about the outputs of the process.

4.6.3.  Perform Integrated Change Control:  Outputs

4.6.3.1  Approved Change Requests

The process can either approve or reject change requests.   If they are rejected, they go into the change log (see paragraph 4.6.3.3 on Project Documents Updates).    If they are accepted, and only if they are accepted, then they are implemented.    They are also put into the change log and this can be used to track their implementation.

4.6.3.2  Project Management Plan Updates

Approved change requests may change one or more of the project baselines (scope, cost, and schedule) or any other component of the project management plan

4.6.3  Project Documents Updates

Project documents may be changed by this process, but the one that is ALWAYS affected is the change log, which documents both those changes which were accepted (in order to track their implementation) and those which were rejected (to record the reasons for that rejection).

This next process is the very last process to be done on the project:  4.7  Close Project or Phase.   This will be the subject of the next post.

Filed under: Uncategorized | 1 Comment »

I am taking a break today from going through my posts on project management to talk about another subject that is near and dear to me:   Toastmasters.   Today is the day that the new Pathways educational program arrives here in District 103 of Toastmasters International in the Chicagoland area.

The educational program as it existed before consisted of four educational award levels (Competent Communicator, Advanced Communicator Bronze, Advanced Communicator Silver, and Advanced Communicator Gold) and three leadership award levels (Competent Leadership, Advanced Leadership Bronze, Advanced Leadership Silver).   If you complete all seven of those levels, then you get the crowning achievement of Toastmasters as an individual, the designation of being a Distinguished Toastmaster.   I joined Toastmasters at the very end of December 2010, so a little more than 7 years ago.  I followed the educational program and, step by step, award by award, finally became a Distinguished Toastmaster in the Spring of 2016.

Since then, I have been waiting patiently for the new Pathways educational program to arrive because I knew I wanted to start from square one again and become a Distinguished Toastmaster again.   It would be as if I were given a chance to go back to college and avoiding all of the mistakes I made the first time around.    So instead of graduating Summa Cum Lousy, this time I’ll graduate Summa Cum Laude!

Pathways is about getting a customized learning path that is geared towards your interests, essentially the answer to the question “What is it you hope to gain from joining Toastmasters?”   Some people want to become professional speakers; some people want to become trainers, coaches, or better mentors; some people want to use the confidence gained in the program to become better leaders.   That latter was my interest, and after the assessment, it chose the pathway of Dynamic Leadership as being the most appropriate.   Each pathway consists of 5 different levels, rather than the 3 or 4 in the previous educational program, and you have to complete 2 pathways in order to become a Distinguished Toastmaster.

But like everybody else in the District, I am starting at square one, so I now am going back to the Toastmasters International website to start my journey.   In the past half-dozen years or so in Toastmasters, getting my first Distinguished Toastmaster award has led to several leadership positions, including being a leader in my church (I am the President of the Board of Trustees), being a leader in our local Project Management Institute chapter (as the Director of Certification and then Director of Executive Council), and of course within Toastmasters itself (as Division Director).    With the new Dynamic Leadership program as my focus area in the new Pathways program, where will my pathway towards my next Distinguished Toastmaster designation lead me?

I can’t wait to find out!

Filed under: Uncategorized | Leave a comment »