A new post will be published January 5, 2026.
Uncategorized
Happy Thanksgiving…
…to my USA followers. A new post will be published December 1.
Decision Making Process Part 5i – Evaluate The Process
#projectmanagement
For the eighth and final step in the decision making process you will evaluate the process itself. You do this in the spirit of continuous process improvement. This will improve your future decision making process and outcomes.
Here are some questions to ask yourself regarding your process:
- For good outcomes:
- What process steps were the most useful?
- What could you have done to make the good outcomes even better?
- For negative outcomes:
- Did the process fail or was it circumstances beyond your control?
- Did you skip steps?
- Were there some steps you did not give sufficient time and energy?
- Did you anticipate and plan for this negative outcome? If not, what would you have done different?
The next post will be the final post in the Decision Making series and I will summarize and give you some additional thoughts on the topic.
My book, “Project Management For The Real World”, is available in paperback and Kindle formats at
Establishing A Project Management Office (PMO) Part 8 – Summary
#projectmanagement
In summary of the prior posts in this topic series, if you are embarking on creating a PMO, you need to treat it like a project. This means appointing a Project Manager and following the usual best practices.
Here are the topics I wrote about in the prior posts:
- Part 2 – The Business Objectives – define the results you want after the PMO is up and running. Establish the mission and clear and measurable metrics to measure PMO performance.
- Part 3 – The Project Objectives – define the PMO organization chart, job titles and descriptions, policies and procedures.
- Part 4 – The Stakeholders – identify who will help establish the PMO and who is affected by the PMO (normally, everyone in the organization).
- Part 5 – The Scope – from the Business and Project Objectives and the Stakeholders, list the major activities needed to establish the PMO.
- Part 6 – The Timeline and the Budget – these are two things that may be constraints on the hiring process.
- Part 7 – Risks, Constraints, Dependencies – understand what can go wrong and have mitigation and contingency plans; know and work within your constraints; identify what other initiatives can affect this one.
Having a PMO is a key step to organizational growth and improvement. Establishing a PMO with a clear mission and measurable objectives is critical to its success.
A reminder that my book “Project Management For The Real World” is available in paperback and Kindle formats at
The Project Management Plan – Schedule Management
Before I dive into Schedule Management I want to note the difference between the schedule and what many refer to as “the project plan”. You will often hear the Microsoft Project artifact referred to as “the project plan”. In reality, it is only the project schedule. The Project Plan is the combination of the Project Management Plan (being discussed in this series of posts), the Project Activity Plan (or Work Breakdown), which will be discussed in future posts, and the Project Schedule. I encourage you to use this terminology correctly.
The Schedule Management Plan addresses the following:
• Indicates how the project schedule will be created (who will be the sources of start/end dates and effort), when it will be base lined and lists any scheduling constraints
• Describes the implementation approach (phased, iterative, pilot, etc)
• Defines what level of the schedule will be subject to change management (typically these are the high level milestones and major phase start/end; all other changes can be informally negotiated)
• Defines how schedule performance is monitored and reported (e.g., variance analysis)
• Defines the project schedule software to be used
• Includes a plan for change management: How a schedule change is requested, authorized, and documented
• Reference the Project Charter for the priority of Schedule in the triple constraints
Schedule Management is a critical part of project management and communication. In future posts I will show how to construct the schedule and monitor performance.
My Kindle book, “Project Management For The Real World”, is available at
http://www.amazon.com/dp/b089krddvn
Now available in paperback!
Decision Making Process Part 5i – Evaluate The Process
For the eighth and final step in the decision making process you will evaluate the process itself. You do this in the spirit of continuous process improvement. This will improve your future decision making process and outcomes.
Here are some questions to ask yourself regarding your process:
- For good outcomes:
- What process steps were the most useful?
- What could you have done to make the good outcomes even better?
- For negative outcomes:
- Did the process fail or was it circumstances beyond your control?
- Did you skip steps?
- Were there some steps you did not give sufficient time and energy?
- Did you anticipate and plan for this negative outcome? If not, what would you have done different?
The next post will be the final post in the Decision Making series and I will summarize and give you some additional thoughts on the topic.
My Kindle book, “Project Management For The Real World”, is available at
Establishing A Project Management Office (PMO) Part 8 – Summary
In summary of the prior posts in this topic series, if you are embarking on creating a PMO, you need to treat it like a project. This means appointing a Project Manager and following the usual best practices.
Here are the topics I wrote about in the prior posts:
- Part 2 – The Business Objectives – define the results you want after the PMO is up and running. Establish the mission and clear and measurable metrics to measure PMO performance.
- Part 3 – The Project Objectives – define the PMO organization chart, job titles and descriptions, policies and procedures.
- Part 4 – The Stakeholders – identify who will help establish the PMO and who is affected by the PMO (normally, everyone in the organization).
- Part 5 – The Scope – from the Business and Project Objectives and the Stakeholders, list the major activities needed to establish the PMO.
- Part 6 – The Timeline and the Budget – these are two things that may be constraints on the hiring process.
- Part 7 – Risks, Constraints, Dependencies – understand what can go wrong and have mitigation and contingency plans; know and work within your constraints; identify what other initiatives can affect this one.
Having a PMO is a key step to organizational growth and improvement. Establishing a PMO with a clear mission and measurable objectives is critical to its success.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Analysis Using Event/Response And Use Cases – Business Events
For the purpose of this analysis approach, “Business Events” are anything that occurs that causes your “business” to initiate a business process. Defining all of the Business Events in scope will lead to discovery of the business process in scope.
There are three main types of Business Events:
- External: These come from outside of your business and you have little or no control as to when or how often these events occur. Examples are “Customer purchases Product” or “Associate requests time off”.
- Temporal: These events happen at regular predetermined intervals. These intervals are required, they are not a business or design decision. Don’t let technology limitations determine the interval. Good Example: “It is time to file quarterly taxes”. Bad Example: “Every two hours the HR system sends employee information to the Financial System”.
- Data/System State: Occur when the data or system reaches a predetermined condition. These are usually Business Rules or Policy decisions. Example: “Product is re-ordered when the inventory level reaches 5”.
The input arrows on the Context Diagram are the starting point for event discovery. In the next post I will define the elements of the “Event List”.
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response And Use Cases – The Context Diagram
The Context Diagram is the place to start when doing your analysis. It should be done in conjunction with the stakeholders that are most knowledgeable about the business processes for the domain under study. The initial list of Business Events will be derived from the Context Diagram.
Start with a circle in the middle of the diagram. This represents the area of the business in the scope of the project. All of the processes within this circle are in scope and are able to be modified or added to as part of the project scope. Think of it as if this business function were outsourced to a service provider and the Executive Sponsor of the project is the CEO of this service provider. What would they need to know to create a business model?
First, you would want to define “who are my Customers?” Your Customers are recipients of your business’s outputs (in most projects, these are flows of information and data). Ask the key stakeholders “who are the current recipients of information your business function?” Draw the Customers as rectangles on the right hand side of the diagram. It is not important at this time that you have the complete list of Customers, only that you have some. We will complete the list of Customers in an iterative process in conjunction with the Event/Response Model.
Next, define the types of information that flow to each Customer. Draw these as arrows from the center circle and connecting to the Customer rectangle. Have a short, high level description of the flow on each arrow.
After that you need to define “who are your Suppliers?” The Suppliers are providers of the business’s information and data. Ask the key stakeholders “who are the current providers of information for your business function?” Draw the Suppliers as rectangles on the left hand side of the diagram. It is not important at this time that you have the complete list of Suppliers, only that you have some. We will complete the list of Suppliers in an iterative process in conjunction with the Event/Response Model.
Next, define the types of information that flows from each Supplier. Draw these as arrows from the Supplier rectangles and connecting to the center circle. Have a short, high level description of the flow on each arrow.
Rules for Suppliers and Customers:
- They can be individuals, roles, departments, organizations, systems, vendors, etc. Anything that is a net originator or receiver of data or information from your “business”.
- Some entities can be both Suppliers and Customers. so they will have arrows going in both directions.
- If you are struggling with whether a Supplier or Customer is inside or outside the circle, the general rule is for entities outside the circle, the project has no control over their processes. The project can only change the nature and content of the information flows to and from these entities.
- There are no flows represented that go from entity to entity. They may exist but they are of no concern to the project.
Here is an example of a Context Diagram:
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response And Use Cases – The Event Model
The Event Model looks at the scope of your project as if this business function is being outsourced to a third party business and your Executive Sponsor is the CEO of that business. This is the new way of thinking about requirements that I referred to in the Overview post.
The Event Model consists of the following elements:
- The Context Diagram – shows your business boundary as a circle in the center of the diagram with your suppliers, customers and information flows surrounding the center circle. I will present this in detail in the next post.
- The Event/Response Model – this contains the detail of the events that “wake up your business” and requires the business to have a planned response. It is progressively elaborated in conjunction with the Context Diagram. More on this in a future post.
- Use Cases – are derived from the Event/Response Model and show the specific steps required for each business response. At the end of the requirements analysis, this becomes (or is the basis for) your “Business Standard Operating Procedures Manual”. Functional Requirements are derived from the Use Cases.
An important thing to remember when creating the Event Model is to keep it independent of technology. It needs to address “what we do” and not “how we do it”. Doing this will help you envision more design alternatives than you would if you locked in a solution at the requirements level.
In the next post I will give you a closer look at how to create a Context Diagram and utilize it to get the requirements discovery rolling.
Note: My Kindle book “Project Management For The Real World”, is available at
Practical Project Management Tips and Tools 