PMO Bytes

What is a project? Project can mean different things to different people in different contexts. Below are some of the common definitions,

From the above, we can deduce that a project is a time-bounded endeavor that has specific deliverables. Put the time factor aside for a moment, a project is then largely characterized by its deliverables, in other words, scope. However, is scope really sufficient to describe and define a project? Before you jump into conclusion, let's do a little thought experiment to explore this further. Imagine that we have a project by the name 'Project Z' with a set of uniquely defined deliverables. If I make a slight change to one of the deliverables resulting in a scope change from Scope 1.0 to Scope 1.1, can I say that Project Z is still the same Project Z? Most of you will agree with me that it is still the same Project Z since a slight change in the deliverables will not change the entire project. This is especially true given that scope change is a common thing in project management. I am also quite sure none of you will argue with me that Project Z is still Project Z if I now make another scope change from Scope 1.1 to Scope 1.2. The same argument applies for scope change from Scope 1.2 to Scope 1.3. What if I keep doing small incremental changes one at a time from Scope 1.3 to Scope 1.4, to 1.5, … eventually reaching Scope X.X where the scope is completely different from that in Scope 1.0? Now, do you still think that Project Z at Scope X.X is still the same old Project Z at Scope 1.0? I am quite sure some of you will shout 'No way!' since we had already mentioned earlier that the scope of a project characterizes what the project should be. If the scope of Project Z at Scope X.X is totally different from the scope of Project Z at Scope 1.0, then the two projects MUST BE DIFFERENT. But wait a second. Didn't we also say that a scope change from Scope 1.0 to Scope 1.1 will not make Project Z a different project? Following along the same line of argument, Project Z should still remain as Project Z from Scope 1.1 to 1.2, as well as from Scope 1.2 to 1.3, … and finally from Scope X.X-1 to X.X. In this case, Project Z at Scope 1.0 and Project Z at Scope X.X MUST BE THE SAME. Some of you must be totally flabbergasted by now as we have just arrived at a pair of contradictory conclusions. So, is Project Z still Project Z? Is scope alone sufficient to characterize a project? What actually went wrong here? I will leave it to you to figure out…

Pushmi-Pullyu (plural Pushmi-Pullyus) is a fictional animal, with two heads at opposing ends of its body, in Hugh Lofting's "The Story of Doctor Dolittle". I am sure all of us had encountered our version of pushmi-pullyus from time to time in the projects that we are managing or have managed. They appeared in different outfits like the demanding sponsor that told you "I want this fast and now" but on the other hand, squeezed thousands of nice-to-have features into the scope, or the clueless user that insisted to have a fast loading page but choked it with bunch of irrelevant charts and images. Have you identified the pushmi-pullyus in your projects? How should you handle their contradicting demands?

Now, let's take a step back and ask ourselves if contradicting demands are really bad? Can they coexist? How can we satisfy opposing demands without having any costly tradeoffs? Is it possible for us to constructively manage the tensions of opposing demands and creatively resolve the tensions thereby, turning challenges into new opportunities? Well, it turns out that we might be able to address this through integrative thinking. Integrative thinking is a discipline and methodology originated by Roger Martin for solving complex and opposing problems. It encourages people to consider broadly, embrace different ideas, think holistically and seek for creative resolutions. This involves going through four basic steps of Salience, Causality, Architecture and Resolution when solving any problem or making any decision. If applied well, integrative thinking may help you to turn a seemingly impossible demand in your project to a well-received deliverable. For example, you may use Moscow method to classify the features requested by the sponsor into must-have, should-have, could-have and won't-have and prioritize them to be delivered over a couple of phases. Doing so allows you to accommodate all the features requested by the demanding sponsor while at the same time able to deliver a workable solution in a short period of time. Are you ready to tame your pushmi-pullyu?

This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was rushing to own it thinking that Somebody would do the job. Anybody could have done it, but Nobody was authorized to work on it. Somebody got angry about that, because it was Everybody's job but Nobody was responsible for it. Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn't do it. It ended up that Everybody blamed Somebody when Nobody was accountable for what Anybody could have done.

Does this sound familiar? It happens to us every now and then in work whenever the roles and responsibilities of individuals are not properly defined. On a similar note, it is crucial for us to have the RACI chart correctly defined in each project to avoid confusion and dispute among the team members. Failure to do so will have adverse impact and in the worst case, jeopardize the entire project. However, before we can even define a meaningful RACI chart, it is important for us to have a good understanding on the definitions of authority, responsibility and accountability in the context of project management and the differences as well as interrelationships among them. They are the fundamental concepts of roles and responsibilities in project management.

Responsibility relates to one's duty or mission. It is an obligation to answer for actions, to ensure that a task is accomplished. A "responsible" individual is one who gets the job done. Authority is the power that is vested in an individual or organization to accomplish a given task or responsibility. It is the ability to act that exerts the necessary control or influence to make things happen. Accountability is being liable for an outcome. It is not just about whether the job gets done, but also how it gets done. Know your Authority, Responsibility, and Accountability in each project. Make sure you have the right Authority to be Responsible for what you are Accountable!

WYSIWYG

What you see may not be what you get. Similarly, what you hear may not be true. This is a common problem many project managers, even the veterans, often fail to avoid in their projects. Do not take face-values as facts. Sometimes, the root cause of a problem may not be obvious. For example, we often hear things like - "The application is slow!". Is it true that the application is not optimized or something else? What is true then? Is the 'blue color' that you are looking at now the same as what I have seen? Color is nothing but an effect due to different wavelength of light. Take a look at the image below. If I say Box A is the same color as Box B, will you believe me?

There is no trickery here, and trust me that your eyes are normal. However, Box A is indeed the same color as Box B. The problem is our eyes see things differently under different environment. Next time when you are conducting an investigation to solve a project problem, ensure that you do a proper fishbone (or Cause & Effect Analysis) diagram to identify the actual root cause before jumping into conclusion. Dive deeper, explore further…

In this PMO Byte, I have created a simple crossword puzzle for those who would like to test out how well they know about the terminologies in project management. I will post the answers in the Comments section later. You may want to give it a shot before looking at the answers.

PM Crossword Puzzle Feb 2011

Across

2.     Tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems.

4.     A diagram that shows what factors can be contributing to an issue or problem.

8.     Mathematical measurement that provides a way to forecast future performance based on what's happened thus far in the project.

9.     Used to translate customer requirements to engineering specifications.

12.   A collection of projects whose objectives are not related to each other.

13.   A schedule network analysis technique.

15.   A task or series of tasks performed over a defined period of time.

16.   A piece of work requiring effort, resources and having a concrete outcome.

17.   Any factor that potentially can jeopardize the successful completion of a project.

18.   A tender document that defines the procurement requirements of a project.

19.   Deliverables-oriented, graphical, hierarchical representation of the work required to fulfill the project scope statement.

20.   A procedure for analysis of potential failure modes by the severity and likelihood of the failures.

21.   This happens when the requirements and work on a project expand in an unmanaged manner.

23.   Sum of knowledge within the profession of project management that is standardized by PMI.

25.   A type of bar chart that illustrates a project schedule.

26.   A statement of the scope, objectives, participants, roles and responsibilities in a project.

27.   Graphical representation of a process, showing sequential activities, branches, and decision points within the process.

Down

1.     The time a task can be delayed without delaying the project.

3.     Member of senior management who supports the project and ensures adequate funding and resources are made available.

5.     An iterative, incremental methodology for project management often seen in agile software development.

6.     A review that is done at the end of the project, during the project closure.

7.     Description of product functions or deliverables that collectively will satisfy the overall business goal.

10.   A contractually required work product, produced and delivered to a required state.

11.   A key event during the life of a project.

12.   A model to analyze and represent the tasks involved in completing a given project.

13.   The practice of identifying, documenting, approving and carrying out changes within a project.

14.   First meeting with the project team and the client of the project.

22.   Matrix for clarifying roles and responsibilities in projects.

23.   A histogram chart showing the values in descending order.

24.   An estimate of funds and/or resources planned to cover a program or project.