PROJECT MANAGEMENT: INSIGHTS INTO THE IMPORTANCE OF CONTROLLING CHANGES

Failing to fully consider the impact of any change often causes major problems. Look at it from the painting contractor's point of view.

A project is born when a stakeholder wants to achieve an objective that will either maintain the status quo, give him an advantage over his competition, or transform a radical idea into reality. These, then, are the three types of projects:

1. Maintenance of an existing function
2. Improvement of an existing function or development of a new product or service
3. Transformative

Of the three, only transformative projects merit an explanation since the first two are self-explanatory. Transformative projects aim for objectives that have never been attempted before. In fact, many transformative projects aim for objectives that have never even been envisioned before. This type tends to cost the most and have the longer durations. Needless to say, these are the riskiest types. On the other hand, if the objective is achieved and it generates the benefits that were hoped for, it can create a new market or even a new industry that will transform the status quo. Some recent and prominent examples were Apple’s introduction of the iPod and the iPhone.

BREAKING DOWN THE WORK

Regardless of the project’s type, the work required in order to accomplish the objective is systematically broken down until it reaches a point where the specific activity can be assigned to an accountable resource. This is called decomposition and it is the essence of a planning task that aims to create the ‘Work Breakdown Structure.” A good example of this would be the maintenance project of repainting the interior of your house. Achieving that objective requires the satisfactory completion of numerous tasks. You have decided to hire a reputable painting contractor to do the job. The contractor’s team consists of a “stripper,” a “preparer,” and a “painter,” and a “cleaner.” The stripper strips old paint. The preparer cleans and prepares the work area. The painter does the actual painting. And finally, the cleaner cleans the work area. These men are resources who are accountable for their individual activities. The sum of their work is called the scope of the project. The individual activity that each resource performs is called a “work package” and was developed through the Work Breakdown Structure.

The project scope is clear. The resources have been scheduled. Now, what happens most of the time? Changes. The paint was already purchased but now, you want eggshell white instead of cotton white. Also, your wife decides that they might as well paint another room. These two requests change the project scope.

An experienced painting contractor will accept these changes but go through some kind of process control. What does “process control?” mean? It means that the before the contractor agrees, he will estimate the additional charges and revenues and determine how he will reschedule his resources.

THE CHANGE CONTROL PROCESS

Formal project management (PM) refers to this as the change control process. It plays an important role in PM. Failing to fully consider the impact of any change often causes major problems.

When the contractor was hired, you had mutually agreed that the painting would be finished in time for your son’s birthday, 15 days away. Faced with these two change requests, the contractor must now do the following:

1. Calculate his additional expense and the fee that he will now charge.
2. Decide what to do with the paint that was already purchased.
3. Determine how he can reschedule his resources that were already scheduled for other jobs.

In formal PM, these three steps constitute the change control process. (For simplicity, assume that his resources—the stripper, preparer, painter, and cleaner—will agree and that's not always going to happen!)

THE 80/20 RULE

You may have heard of the 80/20 rule. It actually has a name: the Pareto Principle. Courtesy of about.com, I present this informative background about it.

In 1906, Italian economist Vilfredo Pareto created a mathematical formula to describe the unequal distribution of wealth in his country, observing that twenty percent of the people owned eighty percent of the wealth.

After Pareto made his observation and created his formula, many others observed similar phenomena in their own areas of expertise. An American pioneer in the field of quality management recognized a universal principle he called the "vital few and trivial many" and reduced it to writing. His work gave academics the impression that he was applying Pareto's observations about economics to a broader body of work. Unfortunately for this pioneer, his original contribution became known as the Pareto Principle. This pioneer’s observation of the "vital few and trivial many" generalizes that 20 percent of something is responsible for 80 percent of the results.

The 80/20 Rule means that in anything a few (20 percent) are vital and many (80 percent) are trivial. In Pareto's original work it meant 20 percent of the people owned 80 percent of the wealth. In the American pioneer’s initial work he noted that 20 percent of defects caused 80 percent of the problems.

Project Managers know that 20 percent of the work (the first 10 percent and the last 10 percent) consume 80 percent of your time and resources. You can apply the 80/20 Rule to almost anything, from the science of management to the physical world. This is an uncanny thing when you think about it.

How can it help you? Whether in business or your personal life, the Pareto Principle can serve as your guide to focus on the 20 percent that matters. Of the things you do during your day, only 20 percent really matter. Those 20 percent produce 80 percent of your results. Identify and focus on those things. When the fire drills of the day begin to sap your time, remind yourself of the 20 percent you need to focus on. If something in the schedule has to slip, if something isn't going to get done, make sure it's not part of that 20 percent. Pareto's Principle, the 80/20 Rule, should serve as a daily reminder to focus 80 percent of your time and energy on the 20 percent of you work that is really important. Don't just "work smart", work smart on the right things.

CH- CH- CH- CH- CH- CH- CHANGES...

This is a list of the most common causes of change:

1. business requirements change
2. business environments change
3. new opportunities or problems arise during the course of the project
4. modifications in the process or system are discovered
5. errors in the process or system are uncovered

The painting contractor has been confronted by a change in the project’s requirements (a different color and an additional room). Assuming he agrees to these changes, he has to do the three activities mentioned earlier, namely:

1. Calculate his additional expense and the fee that he will now charge.
2. Decide what to do with the paint that was already purchased.
3. Determine how he can reschedule his resources that were already scheduled for other jobs.

There is a good chance that the Pareto Principle was at work here. If the original contract involved painting ten rooms for $10,000, it is unlikely that the homeowners will agree to pay significantly more than $1,000 for the 11th room.

They may agree to pay $1,500 but that sum will only partially compensate the contractor for the time and effort he put into recalculations. While $1,500 increases the value of the total contract to $11,500, will it cover the work that the contractor does behind the scene?

THE CONTRACTOR'S DILEMMA

The sum of $11,500 to paint 11 rooms increased his revenue per room from $1,000 (from $10,000 divided by 10 rooms) to $1,045 (from $11,500 divided by 11 rooms). Many paint contractors would rather take the $10,000 rather than incur the additional trouble of dealing with the paint that was already purchased and, more importantly, dealing with the risk of delaying some other projects due to the rescheduling of his resources.

The contractor may have felt pressured to accept these changes simply because of the fierce competition in the paint contracting business. Additionally, most contractors rely on the recommendations of satisfied customers. You and your wife would probably not appreciate nor understand the amount of extra trouble that the contractor went through. It just would not make sense to you especially since you were willing to pay him anyway.

If he turned you down, you would probably not be satisfied customers even if the ten rooms were painted superbly and the entire experience went smoothly. You just wouldn’t understand.

Furthermore, if the two of you agreed to pay the contractor the extra $500 to bind him to finish the project by your son’s birthday, and he accepted, the pressure on the contractor increases. He has to juggle his resources even more carefully.

THE DENTIST

In the world of project management, that deadline is called a time constraint. This project is actually time-constrained before and after the changes. The contractor has no choice but to assign more resources to it in order to finish the project on time. If the contractor could simply not reschedule his resources, he is facing a resource constraint. He has to find additional resources (by hiring temporary help for example) or miss his deadline.

What did we learn? In the formal world of project management, it helps to make the change control process intentionally burdensome. That’s correct—make the process a hurdle, a pain in the rear, a trip to the dentist.

Our mentor—an experienced Program Manager—explained it this way (with some rephrasing on my part).

Most dentists advertise “pain-free” dentistry. That’s well and good but you will not go to the dentist without a compelling reason. In fact, when a tooth starts hurting, you will probably not schedule an appointment immediately. You will wait several days to feel whether the tooth continues to hurt. When you are convinced that the pain will not go away, then and only then will you schedule your appointment. When you are finally seated at the dentist’s chair, the dentist—true to his advertisement—promises that all you will feel is a pinch and then a little pressure.

The change control process should follow this analogy. Your customer should be “taught” that even though the change will be “pain-free” (but not free), she should carefully consider whether the contemplated change is worth the trouble of going through the change control process. If she does, she should be conditioned to feel a little pinch and some pressure. This could take the form of conceding to drop some lesser requirements and, of course, paying more.

You want your customer to weigh the facts. Will the outcome of that change exceed the trouble of undergoing the change control process? If she thinks it is, you, the Project Manager—unlike the painting contractor—should ensure that you charge her in proportion to the trouble and effort of managing the change.

PROJECT MANAGERS NEED BUSINESS ANALYSTS TO SUCCEED. WHY?

I was fortunate to have started as a Business Analyst before becoming a Project Manager. In many ways I think it’s an ideal career path to project management and, eventually, program or portfolio management. In this entry, I explain the reason for that.

Projects are everywhere. We work on them constantly even though we don’t realize it.

Typically, three types are found in anyone’s list of things-to-do. Tasks. Projects. And goals.

Tasks are straightforward activities. Clean the room. Replace the car battery. Walk the dog.

Projects consist of several tasks. Prepare the car for the long trip may consist of tasks like making an appointment with the mechanic, waiting for the mechanic to identify the parts that need to be replaced, tuned up, or repaired, and arranging an alternative means of transportation while the car is being prepared.

Goals are objectives, broadly speaking. Join the family reunion is a goal. Among its projects may be preparing the car for the long trip as well as scheduling time off from work. In this example goal, the explicit objective is to drive a safe and tuned car for the long trip. The idea is to reach the destination safely and minimize the possibility of developing car trouble during the trip.

It’s no different in business. A goal is established and projects emerge to accomplish the goal. Projects, therefore, are essential to the fulfillment of goals and, broadly speaking again, goals are established to either cut costs or increase revenue. All organizations have goals. Therefore, all organizations engage in projects. Projects, therefore, are everywhere. We work on them constantly even while we don't realize it.

ACCELERATION THROUGH TECHNOLOGY

Today, technology has sped up the pace of life. Consequently, competition is more intense. Imagine a company with a better-designed product. It must generate revenue from that product with a sense of urgency. Why? Because it’ll only be a matter of time before competitors introduce their own improved product. The very website that markets the product (technology) is also the window that alerts competitors. There are several ways for competitors to come up with an improved product. For example, it can engineer its own and do so with the same people who created the original. The competitor simply hires the company’s employees. Whether the competitor hires them directly or through a recruiter, technology in the form of email or the mobile phone enables it quickly and discreetly.

This holds true even for a company that possesses a strategic advantage—“strategic” in the sense that its advantage is major or more permanent. Take a company with a grocery store in a better location. Perhaps, it may even be the only grocery in a rural area. The combination of human intelligence augmented by technology—this time for example, in the form of targeted direct mail—can level the field.

MAKING BUSINESS PROCESSES MORE EFFECTIVE

Today, goals tend to revolve around making the organization more competitive. For example, if a hospital can forecast the peak times of its Emergency Department (more commonly known to the public as “ER,” for Emergency Room), then it can schedule its personnel more effectively. Why have four ER personnel during the Tuesday morning shift when it knows that more cases are more likely to arrive that evening? Is it possible to do this? After all, how can it predict the future? Sure, it can and with a high level of accuracy. The majority of hospitals have never applied the statistical principles of forecasting that airlines use. Even long-established methods of manufacturing (like quality control) can contribute to the forecasting.

More effective processes create cost savings, a better bottom line, and a competitive advantage. Most goals, therefore, revolve around improving these processes—re-engineering them to make them more efficient and, ultimately, more effective.

EFFICIENT & EFFECTIVE

What’s the difference between efficient and effective? The best definitions I’ve encountered are succinct: efficient means doing things right (the first time) but effective means doing the right things.

To continue, business processes are frequently a combination of workflows and IT processes. A workflow combines human action and practices. When a patient arrives at the ER, the patient’s information must be collected. Will the workflow consist of the admission clerk writing the information on a paper form or keying it into a computer?

Today, it’s mostly the latter. Data and information, therefore, are two critical components of business processes. Many projects, therefore, are IT-based.

DATA & INFORMATION

What’s the difference between data and information? This is the distinction I prefer: data becomes information when data is put in context. The numeral 2, for example, is data. However, if 1 is the code for male and 2 is the code for female, then the numeral 2, in that context, becomes information.

To continue, projects, especially ones that tinker with processes, must be carefully implemented. An important factor that improves the success rate of projects is careful preparation. In particular, the early phases of any project must be focused on understanding the requirements of the project. Requirements must be clarified in order to ensure that the objective of the project is satisfactorily met.

If the project created an accurate ER forecasting system but the project manager (and his sponsors) failed to ensure the availability of the right combination of medical staff, then the hospital may even be worse off than before. A similar situation may arise if the hospital did not adjust its resources to equip the ER with enough equipment to handle the forecast.

THE COLLABORATION OF THE PROJECT MANAGER AND BUSINESS ANALYST

Successfully implementing a project requires two persons. First is the Project Manager (PM). He focuses on leading the project to its successful completion. However, to ensure that the project’s objective delivers the intended benefit, another person is necessary. This is the Business Analyst (BA). The BA is concerned with managing the business requirements of the project. The business requirements refer to the business benefit of the objective (e.g., cost savings) and to the things necessary to achieve that objective. Poor business analysis leads to inadequate information that, in turn, generates incorrect requirements. Incorrect requirements lead to inaccurate estimates and any project that begins with an inaccurate baseline will likely fall short of its objective.

A project’s requirements span the range from understanding the business case to identifying the processes that will be affected to defining the exact outcome. The last may seem strange but it’s critical to know how the outcome will look like. Will the project objective be met when the forecasting system is in place? Or will it be considered met after the budget has been changed and approved?

Now, isn’t it obvious that a project’s requirements must be captured and fully understood before the project plan is finalized?

The BA has the responsibility of bridging the gap between the user community and the IT personnel. From the former, the BA uncovers their requirements. From the latter, the BA collaborates to design the solution.

In some ways, the BA is more essential to a project’s success than the IT experts. Technical skills can be outsourced but the BA and his skills need to be present in order to uncover the project’s requirements. With that in mind, doesn’t it appear that business analysis should not be treated as subordinate to technical expertise? Many IT experts do not possess the temperament or personality to gather, understand, and analyze business requirements from the user community. Fewer still are able to create realistic solutions that address these requirements since many solutions are a combination of technology and processes.

Many processes involve workflows and, as mentioned earlier, people are typically involved in workflows. Persuading people to change their habits is not an easy task. Changing work habits is especially difficult since workers naturally do not want to be blamed for undesirable results. So delicate and important is this that change, in today’s environment, has evolved into its own management discipline—called, appropriately enough, change management.

Many projects that fail share this condition. The project is initiated, planned, and implemented before the project team and project stakeholders understand the business requirements clearly. This is due, in large part, to our natural belief in technical wizardry and our impatience in old-fashioned techniques of surveys and brainstorming. Too often, the latter activities are rushed. Capable PMs that take over failing projects will realize the problem and force mid-course corrections. Unfortunately, even if the project eventually meets its objective, it will invariably have exceeded its original budget and schedule.

A BA makes valuable contributions in numerous ways. He has created sub-objectives from the primary objective based on a clear understanding of the business case for the project. He has gathered the requirements that the project must meet. He has analyzed these requirements with respect to risk, resources, and time. He has shared these with the PM and project team and assisted them with devise the solution.

This blogpost, I trust, should have made it clear why I think that Project Managers need Business Analysts to succeed.

Business Analysts have a professional organization of their own, like Project Managers. BAs have the International Institute of Business Analysis. PMs have the Project Management Institute.


Link to this blogpost