Thomas Grisham, PMP

PM Choices, By Thomas Grisham, PMP

Introduction

There are a number of project management approaches available that offer business and process choices for companies. The following is not an exhaustive list, but it does provide the most of the major approaches:

**** OGC/APMG – PRINCE2®
*** Project Management Institute – PMBOK® Guide.
*** International Institute of Business Analysis – BABOK®. This function precedes, and follows, the project management project life cycle. In global markets where speed is critical, this function is an important aspect of projects for it establishes the scope.
** International Project Management Institute – ICB-IPMA Competence Baseline
* Agile Project Management – Conceived as a way to accelerate IT and software projects with a variety of approaches including waterfall, staged evolutionary development, spiral model, feature driven development, rational unified process, adaptive software development, crystal, XP, extreme project management, and Scrum.

The number of asterisks shown above represents a qualitative personal view of the amount of structure and process suggested by each approach. So for example PRINCE2® offers an intense process with more data gathering, whereas Agile offers little or no data gathering.

International business and project management practice have converged in the last ten years. Organizations are tending toward multi-talented people, who are self-motivated, intelligent, and willing to take broader responsibility. This is a good thing, but places more responsibility and authority with the Business Analyst (BA) and the Project Manager (PM). Some of the reasons are¹ :

The need for leaner and flatter organizations to reduce costs.
The need for leadership skills throughout the organizational food-chain from top to bottom – lead one day follow the next, and be comfortable personally in either role.
The need for knowledge workers throughout the organization.
Globalization, and the need to improve quality while reducing cost.
Kaizen to keep quality high while reducing cost.
Diversity.

This paper will not provide a detailed view of the pros and cons of each approach, but a rather more basic, and I believe useful, look at the differences. The focus of the paper is on three primary variables: scope, time, and control.

Scope

The primary reason for the failure of projects begins with the clarity of the scope of the work to be performed. The following chart provides an overview of a typical IT project. There is some business need recognized, be it a product enhancement or the development of a new product. Depending on the company, that need would go to a business group, and possibly a business analyst (BA – BABOK® knowledge base). The BA would analyze the situation, develop a scope, write a scope document, get buy-in on the scope, get budgeting for the work, set the time frame, establish the quality required, and turn over the project to a project manager (PM). In the chart this is yellow, and lasts for a period of 6 months. At the end of the project life cycle, shown in orange, the BA would monitor the product to assure it met the needs. The product would then be placed under the control of operations or the business group, shown in green as 36 months. This might be typical of a US$250,000 project. For larger projects, one can substitute years for months.

Now look at the red triangle which depicts some of the basic categories of scope. A performance scope describes how the system is to perform. For example, “the new software platform will be easy to use in six languages.” Frequently, IT projects get this sort of one day/week scope, with little detail, where the scope evolves with the project. Failure rates are high because the amount of work required is not clear, and the due date is often fixed.

A frequently used alternative is equal-to, “please make this project product similar to the one we did last year.” Here the scope is still not detailed, but detail may be available. Quick, low cost, but the risk is clear. These first two options are remote from the detailed specification. Such documents take time and require more funds. That is no guarantee that the scope will be perfect, just less prone to changes. For those of you who have written scope documents, you know how difficult it is to know when to stop.

Think about your own background and training – electronics, hardware, software, engineering, genetics, medical, financial, economic, marketing, business, etc. – and how much cross-training you received in school. For most, self-included, it is precious little. This interdisciplinary type training is accomplished on-the-job, if at all. So imagine a highly trained marketing person-1 who knows what the trends in the market are, but has no knowledge of IT, meeting with an IT person-2 who has a tremendous technical background, but no knowledge of marketing. Now add in a BA person-3 with a business background, a PM person-4 with an engineering background, and place time restrictions on the project, such as that it “must be live in 6 months.” There is not time for a detailed scope document.

On large international projects, say improving the roads in Afghanistan, there is a lot of time, but there are still issues that are difficult to detail - for example, what if asphalt is not available in country. The scope would have to include a whole litany about quality, sourcing, regulations, funding, liability, and etc. Or think about describing the risk of the Taliban, and who takes it.

People have responded with different types of project structures to put a bandage on the scope problem. That leads us to the issue of time.

Time

As noted in the opening, the global economy requires speed. That means listening to the customer, designing a product to fit their needs, delivering it faster than the competition, and it being high quality and low price. Cost, as you all know, follows from time spent. In PMBOK terms there are three primary ways to speed up a project: accelerate it, fast-track it, reduce the re-work.
In acceleration one would increase work hours (say from 8 to 10), increase days (e.g. normal work-week plus Saturdays), or increase people. If a task requires 10 people for 10 days (100 person-hours), work 50 people for 2 days. I have seen this tortured logic more than a few times, and you all know what happens. There are scores of studies that prove extended working hours greatly reduce productivity, especially for those who work with their heads rather than their hands. Most companies have limited resources, and cannot easily add people. Globally, most people tell me they work 50-70 hours per week, and that they work on multiple projects at the same time. So adding hours or days is theoretically possible, but not practical.

To fast-track a project requires doing tasks in parallel, or multi-tasking. As with extended work hours, current research has shown that productivity falls rapidly when people multi-task ². Often on projects the phases are overlapped to save time. I first started doing projects this way in 1970, and have seldom seen them successful. Once when we had a “dream team” we got close, but the project was still mostly sequential. The following chart provides a view from an earlier paper ³ for allPM. The sequential approach of conventional PM is shown at the top of the chart (with 0% overlap), and the Agile approach at the bottom of the chart (with 100% overlap).

Now, look at the chart above and imagine you have a cutting-edge project that is ill-defined – performance specification. Logically the way to proceed is to clarify the scope, then plan, and then execute. But this will take a long time. If Agile is used, the majority of the project will likely be devoted to defining the scope before the time limit is reached (often 3 weeks), and then another Agile project undertaken to continue the work. The danger could be that because of priority changes, when the next portion of the project is undertaken, there might be a different BA and PM, and, with Agile approach no paper trail or transfer of knowledge gained. So to the last issue of control.

Control

The amount of control and the level of detail flows from the approach practices. With PRINCE2® the process, measurements, and reporting are greater than with Agile; as its name implies “projects in controlled environments.” With Agile, in the extreme, there is no documentation and no recorded lessons learned. The time is devoted to doing the work rather than measuring or controlling or reporting. The key is a bit of balance to learn from the mistakes, but spend the majority of time doing the work. So with the PRINCE2® conventional approach, more of the time is devoted to process, control, measurements, adjustments, reporting and lessons learned. With pure Agile, 0% of the time.

Scope changes will occur, always, and can impact a project in many ways but time, cost, and qualities are the three primary challenges. When scope changes occur they must be assessed, re-planning of the project is required, the stakeholders will need to be informed, and management may need to authorize the changes. This takes time, but it provides a reasonable confidence about the results. When doing a pure Agile project, the team simply implements the changes regardless of the impact - shorter, yes, maybe. It may shorten the current Agile project, but may extend the Agile projects that follow. Most importantly, management cannot function on speculation and opinion alone. A BA and PM must provide management with enough hard data to make informed decisions. So there is a yin and yang balance that must, in my experience, be struck.

So what to do? The next section provides a few ideas.

Conclusion

Let us now return to the options described in the introduction, and make use of the second chart. Please understand that what are shown in the following chart are conventional uses of the approaches, and of course there are countless variations. Likewise, the terminology of each step in the sequencing can be different; here I have stayed with the PMBOK® terms for consistency.

The point is that defining scope takes time, either before, during, or after the project. The less is known about the scope at the outset, the more extensive the changes will be, or the more follow-on projects will be required to complete the scope. What I mean is if the true cope of a project were known to be US$1,000,000 with a required duration of 12 months, then the conventional project would have this as the constraints – in a perfect world. If we assume that a Scrum and pure Agile project are constrained to a 3 week project life cycle, the same project would require about 16 projects. Obviously, the danger would be that the overall vision could easily be lost with the pure Agile or Scrum approach. At the other extreme, a market leading product development project that should take 3 months would clearly be best implemented using pure Agile or Scrum. But using the same BA and PM would be of huge advantage.

In my opinion, projects expected to last more than a year with a budget over US$1 million would be better served by a more conventional approach, and those less than 6 months with budgets of under US$0.25 million would be better served by agile approaches.

For long term programs, a blend of the two is a good possibility. In this case a project management officer (PMO) and a program BA (PBA) would provide the continuity for the entire program, with BA’s and PM’s assigned to small projects that can be broken off from the program. This enables the company to keep the vision for the program, but enjoy the benefits of more flexible Agile projects. This option will require a company to rearrange their internal functions, which will result in an initial capital cost, but long term gains in efficiency and productivity.

References

¹Grisham, T. 2009. International Project Management - Leadership in Complex Environments. Hoboken, NJ: Wiley.
² Grisham, T. 2011 Agile, Making It Work. allPM.com.
³ Grisham, T. 2009. International Project Management - Leadership in Complex Environments. Hoboken, NJ: Wiley.
⁴ http://news.stanford.edu/news/2009/august24/multitask-research-study-082409.html
⁵ Grisham T. 2011. Agile, Making It Work. allPM.com.

Dr. Thomas Grisham (BE, MBA, Doctor of Project Management, PMP, PE) has over 36 years of Project Management experience in 53 countries in the power, infrastructure, transportation, education, commercial, communications, manufacturing, business development, and dispute resolution sectors. He also has over 11 years of research and teaching experienc

Artykuł opublikowany dzięki uprzejmości International Institute for Learning, Inc.