Only Reason Projects Fail

It was one fine afternoon in the middle of May, 2013 when I read this forwarded email. It was from a colleague of mine with a subject line “Top 5 reasons projects fail”. Usually, I would glance through such emails for few minutes and move on to the next topic. As I was about to go to my next email, I got this thought. What if I have to pen down my list of top 5 reasons? How different would they be from the lists that I keep seeing once in a while through such forwards?

So, before I started to list down my reasons, I went to Google and searched for the phrase “Top 5 reasons projects fail” and got 31,000,000 results in 0.18 seconds.

Wow, that many results in just 0.18 seconds? I wonder if search engines are actually searching anymore or they have predefined result sets for all common search strings. Guess, someone else is probably more qualified to write a post on this topic. So, let me move on to my genre.

Looking at those results, I was wondering, if so many articles have been written already (and I am sure the age of some of these articles would be at least 20 to 30 years), why can’t project teams learn from the mistakes and not repeat them.

I have browsed through some of those links and this is what I found.

Unclear Goals & Business Alignment	Scope Changes & Change Management	Staffing & Inappropriate Skills
Executive Support	A Lack of Resources	Project Plan Ignored
Stakeholders Not Involved Enough	Not Keeping on Top of Risks and Issues	Extremely detailed Project Plan
Poor requirements	Over-burdened Resources	Scope Creep
Right Stakeholders Not Involved	Issues/risk log, status reports are old school	Ineffective Change Control
Lack of User Involvement	Poor Testing	Poor or No Requirements
Long or Unrealistic Time Scales	Scope Creep	No Change Control System

What else to expect in this list?

If you just spend few minutes looking through this list, its not so difficult to realize that majority of these reasons would fall into the standard triple constraint paradigm namely Scope, Time, Cost, Quality and Risk. Okay, don’t ask me why I listed 5 elements under the bucket of triple constraint. Maybe, we shouldn’t call it triple constraint anymore. Maybe, we should refer these as Penta Constraint.

Nevertheless, the point is, these five constraints are the major reasons projects fail. Why are we even surprised? This is a known fact. That’s the very reason, these five elements are defined as project constraints, to start with. The job of a project team is to work through these constraints to deliver the project while the job of a project manager is to manage the influences of these constraints.

So, in spite of having a team and PM to manage these, if these are still the reasons for projects failure, isn’t this a direct indication that the team and the PM not doing their job properly?

Or, is there something else that’s causing the projects fail? Why do organizations and publishers continue to run after different reasons when the core underlying reason is something else?

Let’s look at one of the most common reasons namely “poor requirements”, which many authors have listed down as a reason for projects failure. Now, what does this mean?

Does it mean that the requirements collection process was poor? Or identifying all stakeholders was done poorly? Or capturing the expectations from the stakeholders was poor? Or translation of requirements into functional specifications was poor? Or the techniques that were used to capture the requirements were inadequate? Or change management of requirements was executed poorly?

In my opinion, “poor requirements” is not a reason. It’s just a symptom and so are the other reasons that you saw in the above table.

For managing each of these (penta) constraints, there does exit a well defined process. If there is well defined project management approach for managing all the project constraints, if the projects are still failing, it’s evident that, the PM and team is probably not able to do their job properly. Maybe the stakeholders are not easy to work with. Maybe the political factors are too complicated. I am sure such “not in my control” factors do play their role in ruining the projects.

Question is, are these “not in my control” factors are the ONLY reasons every time a project fails? Absolutely not! That brings us to the question of “Then, what’s making projects fail?”

Uncertainty is a nightmare

It’s a known fact that, project planning and execution happens amidst lot of uncertainties because the uncertainty is 100% when the project is initiated. Same is the case with risks in the project. That’s why we say a given project is in RED status on day one; not because the project team is doing a bad job but because of uncertainty.

The job of the project manager and the team is to work through these uncertainties and risks and move the project in the right direction (RED to AMBER to GREEN).

Pick few project managers in your organization and interview them with the below listed questions:

• You need to setup milk collection centres in 250 villages that have at least 500 buffaloes. You have an hour to provide time and cost estimates. What will be your approach in getting those estimates?
• Your company is planning to change its name. If this would be a project, what would be the phases of the project life cycle according to you?
• A project is initiated to cleanup a highly polluted lake and you are appointed as project manager. You are given the task of identifying the risks in an hour that need to be presented to the project committee. What would be your approach?

And see how many of them come up with convincing solutions for these. Going by my interactions with several managers in last few years, not many of them could impress you with the answers.

On the surface, none of these questions are actually complex. We do read about scenarios like these in news papers almost every other day. But the interviewees struggle. Those are the same set of folks who do well for other questions which are in their domain. The moment, you step out of their comfort zone, they find it difficult. The reason is quite simple. They can’t face uncertainty.

It’s the project managers’ inability to work in uncertainties that actually causes the failure of projects. And the uncertainty comes in because the budding project managers are not given enough exposure to different areas. Point to be noted, my lord!

This probably answers part of the problem. If you just look around, I am sure you would agree that, projects that are in their comfort zone also fail on many occasions.

Lack of knowledge and Skills

Lack of good competencies, skill and project leadership is the cause for such failures. You pick few project managers in your organization and ask them the below listed questions and see how many of them could actually answer meaningfully and spontaneously:

• What is your approach to identify requirements efficiently?
• List down 5 effort estimation techniques that you are very comfortably with
• How do you define quality plan for a project?
• What will you include in your change management approach?
• What’s your stakeholder management strategy?
• How do you identify who is the right resource for a given activity?
• How do you measure the effectiveness of a peer review?
• If the objective of your IT project is to migrate 475 crystal reports into equivalent SSRS reports, list down three metrics that would define the success of the project

If you carefully observe, answers to the above listed questions have direct association to several reasons mentioned at the beginning of this article.

Lot of guys would struggle to answer all of these questions, meaningfully. Not because they are not smart, but because, they are not provided enough opportunities to learn or experience all facets of a project life cycle.

If you look around the IT organizations, you would find a dedicated testing team, dedicated database team, dedicated operations team, dedicated development team, dedicated middleware team, dedicated deployment team, dedicated release management team and a dedicated project management team.

So, when in the world, would I accumulate good overall experience? Either I am growing to be a developer or a tester or an operational guy but very rarely I will get to understand the intrinsics of all facets of the project.

So, project management is no longer being treated as an “overall discipline”. It has become one of the specialities. Then, why the hell are we blaming project managers when the projects fail? Hang on….why in the world project management is just one another specialized team? Shouldn’t they be the “owners” of the projects?

Project Management is air conditioned

If you just look around, majority of the project managers work form an air conditioned room with an audio/video conference facility. Project management has been restricted to working through the documents and tools. For many PMs, requirements phase is about filling a template.

While I was writing this blog, I asked 6 PMs who work for large MNCs on how many occasions, have they visited their users’ facility to understand how they use the systems or the process that they follow day to day, before putting together any requirements for the projects. The response was only twice in the last 18 months. Between all of them, they have executed 16 projects and only twice they had actually met users at their site. Rest of the times, requirements discussion only happened in a conference room.

It’s a known fact that, running a business successfully involves multiple systems, multiple process and multiple projects. If as a PM, my concentration is only around the project that I am trying to execute and don’t expand my horizon to understand the user/customer’s entire process, I am making my project vulnerable to the influences or changes in rest of the process/projects. Hence, a chance of failure shoots up.

Lack of overall perspective

If you look at the resumes of professionals who started their career in 80s and 90s in services based or projects based organizations, you would find that they would have played different roles in their career starting from entry level engineer to systems analyst to requirements specialist to project leader to quality engineer to database consultant to 1000 other roles. Working with such variety of jobs/roles would have given them different perspectives, ability to work in different contexts, command and comfort with different facets of entire project.

You look at the resume of the folks who have entered the industry in early 2000s, you would see vast difference. The experiences of most of these folks throughout their career would be similar. Similar technology, similar circumstances, similar work, similar domain, similar organizations and similar clients. So, how would even they absorb anything else?

I am not suggesting, anyone from 80s and 90s is by default a good project manager. Rather my point of view is, if I didn’t have enough experiences, it’s difficult for me to become a good project manager.

If I never really did requirements gathering myself, how could I define a good requirements collection process or even review the process assuming someone else defined it.

If I haven’t done much of complex estimation before, how can I validate the estimates that my team is bringing to me?

If I don’t understand how to identify critical paths of my project, how can I even monitor them? By the way, I am not talking about identifying critical paths in a PMP exam book, but in a real time project.

You might say, “Sekhar, I don’t think a project manager needs to have all the skills, he should be able to identify right guys to do the right job.”

Maybe you are right. Let me ask you something. If I don’t have expertise or knowledge about a particular activity (like estimation or requirements or risk identification), how can I even identify who is the right guy to do that job other than depending on others’ opinion.

A project manager is like a movie director. He may not have to do the work of all the departments, but he certainly needs to know how to extract the best from everyone to ensure the movie is a hit. If I don’t know what ingredients a good screenplay should have, then, I can’t verify a script writer’s work. I just have to take it on the face value and might end up burning my movie.

When this gets coupled with Halo effect, the situation gets worse. Because I have been doing well in my technical or functional roles, I would get promoted to become a project manager. I am expected to perform well but no one has time to help me get acquire necessary skills and competencies.

Review is NOT checking what I know

Let me ask you three questions. How many guys in your team can do a review? How many guys in that lot can do an effective review? How many guys from this sub-lot can do world class review?

I can bet my job, the responses for the above three questions would vary drastically and perhaps, the response for last question would be less than 5, if, in fact, it is more than zero.

For most of the folks, review of an artifact is about “let me apply my knowledge and see how I would have done this better” and not about “how far is this artifact from being the best in the world”

Now, I can review a given artifact or work efficiently and effectively only if I am a very effective reviewer or I have enough information and handy tools that can help me understand the best way of executing that artifact or the piece of work.

If I give you a project plan that describes the schedule, Gantt chart, critical path diagram along with quality plan and risk management plan, how many guys on your team would you trust to do an effective review?  If effective reviews are not happening regularly, it has direct implication on quality of the deliverables.

If I just summarize:

• We are not finding many project managers who have good project management competencies and skills and who can provide good leadership for executing projects
• Not many guys are carrying all-round skills
• Effective review is fast becoming a lost art and might soon be found in “American Museum of Project Management”

By the way, I am not saying these are the reasons for project failures. Just like how I quoted earlier that penta constraints shouldn’t be attributed for project failures, same way, the aforesaid three bullet points should also be considered as challenges.

Why project managers are struggling to manage the penta constraint?

Why project managers don’t really have enough skills and competencies?

Why project managers are not getting translated into good reviewers?

There is only one answer to all these questions and that answer is the only reason the projects fail!

Only reason projects fail

The real reason lies in the leadership and management of the organizations. How many organizations are actually investing in developing good project managers? How many organizations are identifying right project management talent and groom them in a planned and systematic way over a couple of years? How many organizations define reviewers’ pool and groom them to be world class? When would organizations stop thinking that sponsoring a PMP or PRINCE certification is a way of developing project managers? How many organizations differentiate between project manager and a project administrator? How many organizations believe that a project managers’ only job is NOT to create tasks in a time sheet entry tool and approve the time sheets? How many organizations believe that project managers’ job is not to fill documents?

If the organizations develop good project managers in old school way and simultaneously develop a pool of world-class reviewers, projects failure would automatically stop. End of the day, projects fail because the penta constraints are not managed properly. And if you have good project managers and effective reviewers, such failure would start coming down fast…very fast!

Metrics by Maturity

It was one fine afternoon in the middle of October, 2012 when I was breaking my head with a tricky situation I was in. I had to execute a 600 person hour(s) worth of work in 21 business days with a 2 member team. I was supposed to share the plan with my stateside counterpart by end of the day.

So, I was putting in different permutations and combinations and suddenly my mobile rang. Usually, I don’t pick any calls if I am deeply engaged in something. I looked at the number and couldn’t help answering the call. It was from one of my college friends, Siva. We haven’t spoken in a while, so, I had to answer the call.

After exchanging the pleasantries, he asked me if I can spare 15-20 minutes. He wanted to talk about his new job and had few questions around that. I told him about the scenario I was trying to solve and asked him if we can catch up in the evening or the next day. Ultimately, we decided to meet the following day for lunch. Since we are anyway catching up for lunch, we decided to invite couple of our classmates, Esther and Master.

Next day, we caught up at this restaurant called BBQ Nation. We started discussing over some ridiculously delicious food.

“So, tell me Siva. What’s your new job?” I asked

“You know, I have been leading a product team for the last few years in my company. Our guys sold that product to a competitor for a great price and started deploying entire team to other projects. Part of that movement, I have been assigned to lead the Operational Excellence team” Siva took a pause.

“Product development to operational excellence…what a move!” Esther was surprised

“It doesn’t seem like a natural transition to me, buddy” pointed Master

“Guys, it wasn’t entirely in my control. Current lead is serving her notice period and there wasn’t much of a choice for my experience level. So, kind of had to accept it in” said Siva.

“Well, everything that happens, happens for good!” I said philosophically

“Guys, need some help. My boss wanted me to put together a proposal for improvising the metrics program in my organization and outside the product development space, I don’t really have much of an experience with other business lines. I don’t know where to start!” Siva stated his problem statement

“What’s the status quo?” I asked

“Well, we have few sets of metrics defined by functional lines such as product sales team, product development team, product maintenance team, product support team and product testing team. They have been in place for the last few years and majority of the teams look good with respect to these metrics. I did a quick search online and spoke to few seniors to determine if there are any gaps. All looks good. So, I don’t really know what else I can improve here” explained Siva.

“It’s similar situation in our company as well. Our operational excellence team defined metrics by functional lines and we provide data for those each month” said Master.

“Same or similar metrics in place for the last few years kind of tells you that there is a great opportunity to improvise” I quoted.

“Hey, don’t fall for this. Sekhar would again open up his project management philosophy” Esther said teasingly.

“Yeah, Esther is right. Don’t worry much about the program. I will send the stuff that we have in our company. Just change the names and present it at your place. Most of the folks do the same, anyway! They copy the templates and processes from their previous company and project it as theirs in their new company” Master added more salt.

“Guys, I am being serious here. I don’t need a solution or a readymade deck. Just help me find right direction and I will build on the top of it” said Siva.

What is a metric?

“Siva, here is the question for you. Define what a metric is for you” I asked

“Any measureable parameter of a project, process or a service” said Siva.

“Yupp...I agree” supported Esther.

“And we measure plenty of them such as SLA, customer service index, number of requests per hour, effort variance, average response per a ticket etc...” added Master

“So, why do you a measure a parameter” I asked

“Okay, buddy, stop treating us like kids.” Esther wasn’t excited to answer such basic questions

“I am sorry, I didn’t mean that way. I was just trying to start at ground zero” I said apologetically.

Why a metric?

“Never mind, Sekhar! She was just pulling you. Let’s continue the discussion. So, you were asking why we measure these parameters. In my view, these are the parameters that tell us how the project/process/service is doing. We would have a target for each of these parameters and metrics would help us determine if we are doing well or not with respect to these parameters.” said Siva

“That’s correct. In fact, they not only tell us if we are doing well or not, but also tell us if we are in the right direction or not” added Master.

Which metrics?

“Cool...now, how do you know which parameters to measure?” I asked again

“Well...it depends up on the goals of the project/process/service, I suppose. For example, if something is service driven, we would look at SLA as a metric and if something is project driven, we look at effort variance, schedule variance, rework etc...” Esther was not going to be left behind

“So, where do your project or process goals come from?” I pushed another button

“From the previous year’s goal sheet!” Master said with a big grin

“That’s funny! At least, my goals come from my business lines’ objectives” said Siva.

“And your goals and objectives remain same year on year” I asked

“Obviously not! For some of the goals, the targets shoot up, while some new goals get added. But for sure, they won’t be same year after year.” Siva replied

“In fact, the objectives of my business line have changed at least by 70% in last 2 to 3 years” supported Esther

“Then, how can you have similar or same metrics measured year after year? Shouldn’t the metrics program get enhanced as the objectives of the business lines change?” I asked

“That’s an interesting point. But my operational excellence team doesn’t even know my business line’s objectives” said Master

“Then, how can they define the metrics for your teams?” I asked again

“Sekhar, it doesn’t mean we should change metrics every year, right? I mean, you need to measure something consistently over a period of time to determine how things are” said Siva

“I am not saying change the metrics every time. I am just saying match the right metrics at the right time. Here is my definition for metrics. A metric is a measurable oriented decomposition of project/process/system/business objectives. So, you should continue to enhance your metrics program as your process/project’s objectives get enhanced” I replied

“What do you mean match the right metrics” asked Esther

“Let me give you an example. When you are setting up a new team for managing a process or an application or a level 1/level 2 support, your initial objective would be to meet the triple constraint which is on time, within budget and with decent quality. Right?” I asked

“I agree.” responded Master

“What about after a year or two? Would you still be interested in being measured for time, cost, and quality?” I inquired

“Of course, not! I think, I would have built enough confidence in my customers by then. If I am still being measured for the same parameters, then, I might have done a bad job” replied Siva

“I think, I am getting what Sekhar is pointing at. If I understand you right, you are saying what was being measured couple of years ago should be a given now and I should focus my attention and measurements on bigger and better objectives.” summarized Esther

“Right...that’s one point. There is another interesting aspect to the metrics program. Let me ask you a simple question. I am sure there would be a monthly or bi-monthly report that gets presented in your organization as part of metrics program.

How many times do you actually look at that report with genuine interest? How many times, does that report convey that there is a problem or a potential problem brewing in your project/process/application/program? On how many occasions have you ever opened a prior report for validating certain things?” I asked

“Never” said Master.

“Once or twice” Esther replied.

“Siva, that’s the improvement you could make in your metrics program. End of the day, if the output of metrics program is going to be an FYI, then, it’s not entirely serving the purpose. There should be no more than 50% FYI metrics in your report. At least, the other 50% should present you actionable information.” I summarized

“That’s a good input for me. Tell me more” Siva is curious now.

The Operational excellence philosophy

“Consider an application team that’s setup for the first time. Like we discussed earlier, their initial objective would be to deliver on time, within budget and with good quality. Now, to measure these objectives, I probably would use measurements such as effort variance (within budget), Schedule variance (on time), rework percentage and defect density (good quality). It’s typical that on a monthly or a bi-monthly basis, I would share these metrics with the customer or business.

Let’s say, 7 to 10 projects were executed in that application over a period 18 to 24 months meeting these objectives. By now, the customer or the business would be more than happy with the ability of the team. So, for them, getting a quality deliverable on a timely fashion is a ‘minimum’ expectation. They don’t hope for or anticipate a quality deliverable any more. They expect it by default. In other words, they won’t really care about these metrics anymore. So, what is the point in producing/sharing the same set of metrics again and again?” I elaborated

“That’s an interesting question. So, are you suggesting that, we shouldn’t capture/share those aforesaid metrics anymore? In case we don’t capture them anymore, don’t we run into the risk of not knowing when things actually go wrong from schedule and cost perspective? ” asked Siva

“No, I am not suggesting that. I was merely saying, sharing just those metrics won’t really help in anyway. They have now become hygiene metrics. These would be your FYI metrics now. You need to come up with next set of objectives and start measuring those. That way, you would still keep an on eye on your hygiene metrics but focus on next objectives.” I replied

“Sounds interesting enough...please elaborate more” asked master

“Continuing the same example that we discussed earlier, once the team is on the top of cost, time and schedule kind of metrics, you can turn focus on to Product Quality metrics or Process quality metrics or User experience metrics or Business quality metrics or even People quality metrics.

You could say, now that my delivery is continuously stable, let me focus my attention to improve my user community experience. As an example, if they are using the application to underwrite loans and if there was a series of 10 steps that take about 25 minutes to enter data, I could always look at ‘how can I reduce the time or automate some of those steps or reduce the steps so on and so forth’.

Or you could say, now that my delivery is continuously stable, let me focus my attention to improve the maintainability or testability of my application. As an example, if quality assurance activity, on an average, takes 3 weeks for projects, how can I bring that down to 2 weeks so that ‘Time to Market’ is improved for my business.” I elaborated

“Sounds like an idea. But, how do I know where to focus. Should I focus on product quality metrics or business quality metrics or user experience metrics? How do I determine that?” asked Siva

“Good question. I call this concept Metrics by Maturity. For any process/application/ system/service, spend time with its owner, business and technology teams and understand what the maturity cycle of that entity is. Maturity cycle can be derived out of the expectations of the business/customers. Answers to few simple questions, as listed below, might help derive the maturity cycle.

• What is your immediate need from this process/product/system?
•  How do you see this process/product/system shaping up two years from now?
• What is the roadmap of the business that this product is serving to?
• What role do you expect this process/product/system to play in the business? In other words, which objectives of your roadmap are expected to be addressed by this process/product/system

Again, as an example, you could have a four stage maturity cycle:

•  Stage 1 would be Stable output, where the business might say, ‘Hey guys...Don’t worry about anything else, just give me quality deliverable on time’. So your metrics would be effort variance, schedule variance, rework %, defect density, SLAs etc...Lot of times, standout performances from few team members would do the difference here.

• Stage 2 could be Stable product, where the technology team might say, ‘Hey guys...now that we are comfortable with the delivery, let’s focus on product quality metrics and turn our application into a well manageable, maintainable, configurable and testable application so that our stage 1 (stable output) won’t depend on individual brilliance anymore’. For a software product, metrics for this stage would be Cyclomatic complexity, code coverage, Maintainability metrics, Package metrics etc...

The point to be noted here is that if your project is to develop a product, you might combine both stage1 and stage 2

• Stage 3 could be Enhance business value, where the product team might ask the business or customer, ‘Hey guys...now that our delivery is quite stable and we have turned the application into better manageable one, please tell us how we can improvise this into more profitable product?’ For customer facing process/products, such metrics could be time it takes to add a customer, number of times a customer had to call customer service for a feature that’s already available in the product, % of reduction in customer calls or service requests, average time customer spends on a customer service call, % of effort a user spends to prepare the data to enter in to the product, analyze the data after downloading from the product etc...

• Stage 4 could be Lights-on Maintenance, where the business might say, ‘Hey guys...we are not going to enhance this product anymore, we just need its existing features to be available without any interruption. So, put just enough effort on this to resolve any tickets or queries as fast as you can’. So your metrics could be SLA, effort consumption per ticket, % of ticket reduction etc...

Note that these stages and their order wouldn’t have to be the same. You would have to derive the maturity cycle of your process/product/service based on the roadmap and expectations of various stakeholders.” I concluded my long speech

“I think I got few inputs that I was looking for. Let me put something on the paper and see how it comes out. If things go well, I will buy you lunch next time but for today, let’s go dutch” Siva ended the luncheon!

ఓం నమో ప్రాజెక్ట్ మనేజ్మెంతాయ నమః

How do you define status color code (Green, Amber, Red)?

It was one fine Tuesday afternoon in the middle of July, 2013 when I was browsing my piles of pending emails. Daniel Reddy, a colleague of mine dropped by my desk. Looking at him I know there is something messed up. Preparing myself to hear out Daniel, I said, “Let’s go to cafeteria and have a masala tea”. He looked little disturbed and said “No, let’s chat here. I ran into some trouble.”

“Okay. What’s going on” I asked.

“You know about the EZ-Audit project right.” He asked.

“Of course, I know! Everyone knows about EZ-Audit project. It’s supposed to be the next big thing in the company. What about it?” I inquired.

He said “You know, we were going to setup a team of 15 for this project and the domain training was to start from next Monday for which a trainer from States was going to fly down. We rolled out the offer letters for all of them about 2 months back. 7 of them joined last Monday and 8 more were to join yesterday (Monday). However, only 3 of them showed up yesterday and 5 of them didn’t join and we can’t reach them on phone either. Looks like, they might have taken our offers and joined elsewhere.  Now, we are in all sorts of trouble.”

“Relax. I don’t know how much blame you can take for this. Granted, your stateside team won’t be happy about candidates not showing up, but it’s not something that you can control.” I tried to make him feel better.

“No, buddy, the problem is not only about the guys not showing up. That’s only part of it. Bigger problem was, my Stateside SVP was really upset because, the status report that went out last Friday showed the project status as GREEN and suddenly by Monday evening, the project entered into RED. She is quite upset that, how could project status change over a weekend from GREEN to RED” he clarified.

“Okay, you need to slow down. There are too many Mondays and Fridays that you are referring to. Help me understand in little detail” I asked.

“Okay. Here is the whole story. This whole thing began sometime in April 1^st week. Our Insurance audit department in States wanted to start a new BPO team for processing back office audit transactions. Over the next couple weeks, we finalized the approach, team composition and next steps. I initiated the recruitment and at the same time, we also have listed down other activities such as identifying the cubicle space, purchasing the hardware including a finger print devices, procuring specialty software so on and so forth.” He took a pause.

“I prepared a detailed project plan and initiated all these activities in parallel and started sharing the weekly status updates to all stakeholders” he continued.

“Except for first couple of weeks, we are always running faster than the plan and so we were pretty much in GREEN all along. Except for the 5 guys who didn’t show up, all other activities were completed well ahead of time. Hence, our weekly status was always GREEN and that’s what we shared last Friday also. But since the team didn’t join this Monday, the whole thing has gone for a toss. Now, the stateside manager is not ready to send the SME to train the team here unless we get another couple of guys at least and so, it delays the whole planning. That’s why the project has moved into RED now.” He concluded.

“So, your stateside manager is upset because there is a delay in the process due to non-joiners and perhaps even more upset because you kept telling her the project was in GREEN all along and suddenly, it’s in trouble without any heads up. Is that what it is?” I clarified my understanding

“Yes. That’s correct.” He responded

“So, tell me, when you mentioned status as GREEN, what have you considered each week.” I asked

“I considered the project schedule and how all planned activities are doing against their target dates, and any issues and risks. Like I said, except for first couple of weeks, all the project activities were well ahead of the plan and there were no major issues or risks. We did capture few risks but as we kept moving, those were mitigated except for these ‘no-shows’. How could I give the status as RED just by anticipating that, 30% of the team may not show up?” he was understandably upset.

“Buddy, I think you missed out few critical points for your status consideration. Status code of GREEN/AMBER/RED shouldn’t just depend on project schedule and issues/risks. It has to be little more than that.” I clarified.

“Like what?” he was little more upset that I was probably adding insult to injury.

“What is the status of a project on day one”, I asked him.

“What do you mean on day one. What else can it be other than GREEN?” He replied as if I was asking a stupid question.

“Why do you say so?” I asked

“Because, on day one, you don’t have any pending activities. How could it be anything else other than GREEN?” he questioned again.

“What if I say, on day one of any project, its status is RED?” I quizzed

“RED…!? Why would that be?” he was confused

“Because, there is lot of uncertainty in the project and the probability of successfully completing the project is very little. You don’t have much clarity on what you going to do except for a project initiation document or a project definition document. So, shouldn’t it be RED?” I asked

“Well, your uncertainty and probability piece is making sense, but in that case, the only day the project can be in GREEN, is the last day, right? Because only that day, you are 100% sure, the project is going to be completed, isn’t?” he asked

“Well, technically, yes” I replied.

“Oh...common...it’s absurd. If that’s the case, all projects in the world would be in RED status all the time. Tell me something else for heavens!!” he demanded

“Well, that was a technical answer. But the reality is, as the schedule progresses, the uncertainty reduces and probably of successfully executing the project increases. So, the status doesn’t necessarily have to be RED all the time. What you told me was you considered project schedule and issues/risks to arrive at your status right. I think that’s a good start, but my point is those two parameters are not the only pieces. ” I replied

“Sekhar, I don’t know if I am getting you completely.” he said with a question mark face

“Let me elaborate. You said, purchasing hardware was one of your major activities, right?” I asked

“Yeah...so...?” he was puzzled

“Let’s say, you break that down into five sub activities namely 1) Work with the stateside team to identify the hardware requirements 2) Work with vendor management team to identify the vendor 3) Work with the supply chain management (SCM) team to place the order 4) work with customs authorities to procure the order into premises 5) Wok with the infrastructure team to setup the hardware.

Let’s say, you were to complete the second sub activity by 20^th of May and let’s assume that you, in fact, did meet that date. So, you were saying, since I was to complete two sub activities by 20^th of May and I did that, the status of procuring hardware activity is GREEN.

But, there are 3 more sub activities that are dependent on three different set of stakeholders. So, still lot of work needs to be done. Which means, although you are doing well from the perspective of what has been planned to complete, there is still uncertainty for the other three sub activities. So, you are GREEN only for 40% of the sub activities and NOT-GREEN, yet, for rest of the 60% of the sub activities. Then, how can the overall status of “Purchase the hardware” be GREEN? Shouldn’t the status of it be a combination of 40% GREEN and 60% NOT-GREEN?

“Man…you are actually making some sense to me now. I liked that 60% NOT-GREEN point! What should that NOT-GREEN be? AMBER or RED” he asked

“Well, it can be AMBER or RED or even GREEN based on your comfort/confidence level. As an example, if you have already spoken to SCM team and infrastructure team and set the expectations and shared some plan with them in terms of what to expect, then, you are more towards LIGHT AMBER or LIGHT GREEN, but if you haven’t spent any time with them and you are waiting for second sub activity to be completed, then, you might as well be RED for those 60% pending sub activities” I replied

“Sekhar, let me digest what you said. You are suggesting that we should not only look at the past performance of the project, but we also need to consider the pending activities of the project. And on the top if it, like I mentioned before, we should also consider issues/risk, right? So, essentially, we have to consider three parts to arrive at the status?” he asked

“Well, there is one more critical piece” I replied

“Really? What would that be?” he asked again

“Show stoppers…!” I was forcing him to think

“Show stoppers…!?? What are they?” curiously he asked

“In some senses, show stoppers are nothing but your most critical risks. Let’s say you identified 7 risks as part of your initial ground work. Some of them could be simple ones and some complex. For some of them, you may have mitigation plan and for some of them, you may chose to live with them. But if you just keep those 7 under the same bucket called Risks and treat them as one unit, you might run into trouble. Hence, you always need to call out those risks that could potentially bring your project to its knees and classify them separately under another bucket (show stoppers or any other name).

As an example, customs authorities not giving approval for the hardware is a show stopper. Prospect joiners not showing up on date of joining is a show stopper. SME quitting a week before the travel is a show stopper.” I concluded

“Buddy, I have been doing Risk Management for a while now even adhering to the PMBOK standards. But I haven’t come across this term Show Stoppers anywhere.” He said.

“That’s true. But end of the day, Project Management is common sense and you should tweak the guiding principles that PMBOK has published or for that matter anyone else published in such a way that it suits the real world. You don’t have to call them show stoppers, use another name. It doesn’t matter.” I replied

“Yeah...guess…you are right” Daniel was in acceptance mode.

“Okay. Here is the equation for a project status code that I often use” I continued.

Status =

performance of the planned activities against the plan

X

expected performance of the pending activities

X

impact of issues and risks

X

impact of show stoppers

"So, look at the equation one more time. All I am saying is, instead of just looking at what’s planned versus what’s completed, go little further. Think about your comfort level on the pending activities, consider all risks and issues at hand and more importantly, state the impact of show stoppers explicitly.” I concluded

“Think about it. Within the first few weeks of the project initiation, 1) you notify all key stakeholders about the approach you would take to publish the status report (such as above one), 2) identify and publish the critical show stoppers and 3) the impact they may have on the project deliverables, when actually things get delayed, it no longer is a surprise for anyone. So, naturally, people might be disappointed with the delays, but they won’t be upset or annoyed with the project manager. In fact, they would appreciate you for being detailed and proactive!” I concluded my funda of the week!

“Thank you, buddy. Let’s go for a cup of tea now. It’s on me!” he pushed me out of my space!

ఓం నమో ప్రాజెక్ట్ మనేజ్మెంతాయ నమః