Year: 2021

Establishing A Project Management Office (PMO) Part 2 – Business Objectives

Professor of Project Management General

If you have been following this blog you will recognize a common theme in almost everything you want to do: Know your outcomes (aka “Business Objectives”). Before establishing a PMO, you need to understand the PMO Sponsor’s vision of what problems they are trying to solve and/or what opportunities they wish to exploit.

Here are some possible problems your business may face that can be mitigated by having a PMO. You may have one or more of these to solve:

  • We aren’t maximizing our Return On Investment (ROI) from our portfolio of projects.
  • Our project mix is not aligned with our long and short term business goals
  • We don’t have control of our project request process
  • We have key resources frequently overloaded causing project bottlenecks and delays
  • Our projects are usually late
  • Our projects are usually over budget
  • We under-deliver on the agreed upon scope
  • Our projects often have the scope expanded without knowledge or approval
  • Our project quality is frequently lacking
  • We take on too much risk
  • We don’t take on enough risk

Depending on the problems you wish to solve, here is just a sample of the measurable business outcomes you can obtain my investing in a PMO:

  • Regular financial analysis reviews showing the ROI on the current active project portfolio and the ROI on alternative combinations of projects
  • No resource bottlenecks; Resources obtained and deployed in the most effective manner
  • Deliver projects on or under the approved schedule and budget
  • Deliver on the approved scope
  • Control how much risk we are taking on (possibly by regular review of the risk/reward matrix of the current portfolio of projects)

In the next post I will present some possible Project Objectives for the establishment of a PMO.

A reminder that my Kindle book “Project Management For The Real World” is available at

ww.amazon.com/dp/B089KRDDVN

Advertisement

Establishing A Project Management Office (PMO) Part 1 – Overview

Professor of Project Management General

If your organization is embarking on creating a PMO, congratulations! You will typically find one in the best run companies. If you are not sure how to go about it, I will offer some guidance and suggestions in the upcoming series of posts.

Creating a PMO is a goal. Presumably, you want to have it done by a target date. The combination of a goal and a target date means you have a project! You should treat the establishment of a PMO as a project and use formal project management techniques to do so.

Here are the topics I will address in this series:

  • Part 2 – The Business Objectives
  • Part 3 – The Project Objectives
  • Part 4 – The Stakeholders
  • Part 5 – The Scope
  • Part 6 – The Timeline and the Budget
  • Part 7 – Risks, Constraints, Dependencies
  • Part 8 – Summary

Something as business critical as creating a PMO should never be done via undocumented, ad hoc conversations. Following the guidelines I provide in the upcoming posts will give you a much greater chance of success.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://www.amazon.com/dp/B089KRDDVN

Studying For The PMP Exam Part 2 of 2

Professor of Project Management General ,

In part 1 of this 2 part series, I gave you some good reasons why you should get your Project Management Professional (PMP) certification from the Project Management Institute (PMI). In this part, I will share the methods I used to prepare for the exam.

There are many excellent exam prep courses available but they are usually very expensive (over $1,000) and in my opinion are not necessary. If you are comfortable with self-study, you can prepare for this exam for a lot less money.

Here is what I did:

  • Purchased a self-study book that had excellent reviews
  • Took as many free practice exams as possible

The book I used and the one I recommend is “The PMP Exam: How to Pass on Your First Try” by Andy Crowe. The author does an excellent job leading you through everything you need to know, with practice exams at the end of each chapter. The most important thing this book does, though, is change the way you think about project management to be in alignment with how the PMI wants you to think about project management. If you go into the exam trying to pass just based on your project management experience, in the words of Andy Crowe, “The exam will chew you up and spit you out.”

I personally went through the book three times to make sure I thoroughly understood the material. You will have to decide for yourself how many times you will need.

The other thing you need to do is practice! There are many free PMP practice exams available on the internet. Just use Google to find them. A general principle in learning anything is to “try, fail, correct, try again”. This is the best way to master any skill or subject. The practice exams will reveal your areas of weakness, where you need to focus your study time. Take as many of these as your schedule allows. I even found one that had a full 200 question, four hour timed exam. That was a very valuable exercise. The practice tests in the Crowe book tend to be a bit easier than the real exam so you need to seek out difficult practice questions.

Be prepared to put in many hours preparing for the exam. It is not a slam dunk and you need to be well prepared. I studied over the course of six weeks, about 1-2 hours per day. If you fail the exam there are no refunds and you will have to pay to take it again so it is in your best interests to pass on the first attempt.

Good luck to all of you preparing to take the exam!

A reminder that my Kindle book “Project Management For The Real World” is available at

http://www.amazon.com/dp/B089KRDDVN

Studying For The PMP Exam Part 1 of 2

Professor of Project Management General ,

If you are planning either a career in project management or having project management as a critical part of your job function, you should absolutely get your Project Management Professional (PMP) certification from the Project Management Institute (PMI). There are two primary reasons for doing this:

  1. It will greatly enhance your job opportunities and career advancement prospects. The PMP certification is a validation of your knowledge and experience, and shows a commitment to ongoing education in the discipline. Many organizations use the PMP certification as a filter to select qualified candidates to interview. Without the PMP, in many cases you will not even be able to get a phone screen interview.
  2. It will make you a better Project Manager! In my personal experience, just studying for the PMP exam will improve your abilities as a Project Manager. How? It will introduce you to processes, tools and techniques you will likely have never used as a “seat of the pants” Project Manager. You will use this additional knowledge in your future projects and see how they greatly improve the quality of your outcomes.

You cannot go into the PMP exam hoping to pass it just based on your project management real-world experience. The PMI wants you to know and understand best practices, and also wants you to approach project management using their paradigm. You cannot pass without knowing these things.

In Part 2 of this post, I will share with you the methods I used to study for and pass the exam on the first attempt. It didn’t cost anywhere near the $1200 or so some companies charge for PMP prep classes. I hope you find it useful and informative.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://www.amazon.com/dp/B089KRDDVN

Requirements Elicitation Techniques Part 14 – Summary

Professor of Project Management Requirements Analysis
Planning

In the prior posts in this series, I introduced the following requirements elicitation techniques:

  • Part 1 – Overview
  • Part 2 – Acceptance Criteria
  • Part 3 – Benchmarking
  • Part 4 – Business Rules Analysis
  • Part 5 – Data Modeling
  • Part 6 – Document Analysis
  • Part 7 – Interviews
  • Part 8 – Non-functional Requirements
  • Part 9 – Observation
  • Part 10 – Prototyping
  • Part 11 – Root Cause Analysis
  • Part 12 – Surveys and Questionnaires
  • Part 13 – SWOT Analysis

These are in addition to the Business Event/Response technique which I discussed in detail in a prior series of posts. These techniques can be considered a “toolbox” from which you can select the appropriate tools for the job. You will likely never use all of these in a single project. Based on the type of project you are working on, you will select the techniques that fit the size, background and scope of the project. Every Project Manager should have familiarity with these techniques and be able to apply them. They are core techniques in the Business Analyst’s Body of Knowledge (BABOK).

If you are a Project Manager and don’t currently perform the Business Analyst function, I encourage you to get training in this area. PM’s that can perform this function are immensely valuable to their organizations.

Feel free to leave comments on your own experiences as a Business Analyst. Include what worked well, what didn’t and why.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://www.amazon.com/dp/B089KRDDVN

Requirements Elicitation Techniques Part 13 – SWOT

Professor of Project Management Requirements Analysis ,
Planning

The acronym SWOT stands for “Strengths, Weaknesses, Opportunities, Threats”. It can be a useful tool to analyze a business process undergoing change. Honest evaluation from all parties is important here. The group undergoing the evaluation must not feel threatened by the analysis. Note that “Opportunities and Threats” are external factors beyond the scope of control of the assessed group.

As with all endeavors in the field of project management, always make sure you have first defined your objectives and expected outcomes of the analysis. This will ensure that proper use is made of the results.

The SWOT evaluation team should be comprised of a cross-section of middle and upper management of the business process owners, as well as those who actually participate in the execution of the business process. The team should be instructed to first identify the Strengths, Weaknesses, Opportunities and Threats independently to avoid group bias. Then the group is brought together to compare notes and agree on the final list.

You proceed to make a matrix with S and W as the rows and O and T as the columns. The cells are filled in by the evaluation team as follows:

  • SO – How can the groups strengths be leveraged to exploit the potential opportunities?
  • ST – How can the group use its strengths to ward off potential threats?
  • WO – Can the group use an opportunity to eliminate or mitigate a weakness?
  • WT – Can the group restructure itself to avoid a threat?

The answers are analyzed to determine cost of implementing vs. value and from that you can determine which of these the project sponsor wishes to include as part of the business requirements for the project.

Requirements Elicitation Techniques Part 12 – Surveys And Questionnaires

Professor of Project Management Requirements Analysis
Planning

For some projects you may need to gather information from many people in a short time. When you have this condition, surveys and questionnaires can be very efficient.

First lets define the terms. A survey encompasses all aspects of the research process (design, construction, sampling method, data collection and response analysis). A questionnaire is a tool used for a survey and is a set of questions with a choice of answers.

Let’s look at the steps to conducting a requirements gathering survey:

  • Design – You will need the answer to questions such as “What are the objectives?”; “What media will be used?”; “Who will it be sent to?”; “How long will be given to respond?”; “What will you do with non-responders?”; “Who will compile and analyze the data?”
  • Construction – “Who will determine the questions to ask?”; “How many questions will be asked?”; “Will you allow open-ended responses?”; “Who will create and distribute the questionnaire?”. A tool such as Survey Monkey can be useful.
  • Sampling Method – You will need to define the target population. If the entire population is sufficiently small, you can include everyone. If the population is large, you will need to use statistical sampling methods. Consult the statistician on your team or company for advice on the various methods.
  • Data Collection – The method of data collection should have been determined in design. Collect and summarize the data as a prerequisite to response analysis.
  • Response Analysis – This ties in to the objectives you defined in design. The method and people involved were determined in design. The responses are used to guide the direction of the requirements.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://amazon.com/dp/b089krddvn

Requirements Elicitation Techniques Part 11 – Root Cause Analysis

Professor of Project Management Requirements Analysis
Planning

The purpose of root-cause analysis is to determine the underlying source of a problem under study. Doing this will help ensure the requirements attack the real problem and not just the symptoms.

A critical element is to challenge the current business thinking and processes. You want to overcome the “we’ve always done it that way” answer to the question “Why do you do this?”. I recently managed a project where it took interviews with dozens of people to finally get the answer to the question of why the pay week started on a Saturday instead of Sunday where the sales week started.

The steps to root cause analysis are:

  • Define the problem under study and understand the impact
  • Analyze the problem to determine the root cause
  • Agree on solutions to prevent the problem from occurring

One technique to analyze the root cause is the “five whys” to explore the nature and true cause of a problem. This means repeatedly asking “why” after a question is answered until you uncover the real root cause. It may be more or fewer than five, but five is a good rule of thumb.

You can create a visual of your “five whys” analysis using a “Cause Map”. A Cause Map is simply a block on the left that identifies the problem, an arrow labeled “why” going left to right to another block that answers the question, then an arrow labeled “why” going left to right to the next answer and so on until the root cause is identified.

Root Cause Analysis is a good addition to your requirements analysis repertoire. If your project is not addressing the true root causes of the problem definition then you are unlikely to achieve the defined business objectives.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://amazon.com/dp/b089krddvn



Requirements Elicitation Techniques Part 10 – Prototyping

Professor of Project Management Requirements Analysis
Planning

Prototypes are the shell of an actual production application and are used to provide insight into the look, feel and flow of an application. The main purpose is to gather requirements related to the user interface. A “throw away” prototype seeks to quickly uncover and clarify system interface requirements. It is especially useful in cases where the most efficient workflow can only be discovered with hands-on experience.

Some have made the mistake of thinking prototyping is all you need to do to gather requirements. This will almost always be a costly mistake! Other requirements techniques will need to be used to get a complete set.

When you obtain the user interface requirements using prototyping, the next step is to integrate these requirements with your use cases, scenarios, data model and business rules. Your new discoveries will usually result in changes to previously gathered requirements.

There are two categories of prototypes used to uncover functional scope:

  1. Horizontal Prototype – models a shallow and wide view of the system’s functionality. It typically does not have any business logic running behind the visualization.
  2. Vertical Prototype – models a deep and narrow slice of the system’s functionality. There usually will be some business logic built to uncover complex requirements.

It is a judgment call as to whether or not to use prototyping on a particular project. You must weigh factors such as the importance of the user interface, the clarity of the requirements gathered via other methods, the difficulty in building the prototype, and time constraints.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://amazon.com/dp/b089krddvn

Requirements Elicitation Techniques Part 9 – Observations

Professor of Project Management Requirements Analysis
Planning

In many cases of gathering requirements, there is no substitution for actually observing the process as it happens. You will find that often the way things are done contradict what is written in process manuals. These deviations are important as they usually reveal an inefficiency or deficiency in the process, and the user felt the need to employ a different method. This is valuable information for process improvement!

You should be aware that at times just the fact that a process is being observed can make the user change how they usually do things. It is important to make the people being observed comfortable with why they are being observed and the objectives of the observation. Openness and honesty are important. Solicit their input and suggestions.

As with anything project related, there needs to be a plan. You can make a simple form with elements such as:

  • Process Name
  • Observation date(s) and times
  • Observers
  • Location
  • Purpose/Objective
  • Notes
  • Key Findings

The dates and times are important as you need to know if this is considered peak/normal/low volume time. This is a key consideration regarding the observation objectives.

After the observations are complete, you should meet with key project staff and stakeholders to discuss findings and their impact on the requirements.

A reminder that my Kindle book “Project Management For The Real World” is available at