Project status showed GREEN till yesterday and today it is all RED! Does this sound familiar?

Maybe, it has been RED for a while, but somehow, the RED did not become visible till now. And this often happens at the eleventh hour when fire-fighting is the only option left.

How do you assess the true status or health of a project? And how can you provide your customer of an assurance of positive outcomes during all stages of the project?

I had an occasion to talk to my colleague, Ananth, exactly about this. This is the second part of my discussions with Ananth.

Click here to see Part 1 of the discussions

Paramu

On the surface, the framework looks logical and fairly intuitive. Where does its power come from?

Ananth

There are three key aspects to the framework:

  1. Firstly, it paints a vivid picture of a vibrant project through easily understood manifestations while allowing room for contextual nuances.
  2. Secondly, its multi-dimensional nature makes it possible to see the health from multiple angles and enables focus (by grouping into vital signs and components) for improvement actions.
  3. Thirdly, it not only covers the attributes of basic health but also has deeper pointers for stronger execution that can withstand the vagaries of a software project environment.

Paramu

Ananth, could we look at a project scenario to understand how to make sense of the framework?

Ananth:

Okay. Let us take a project I worked on before. I will use the present tense to talk about the project.

Paramu

Okay

Ananth

This is a large offshore development project – 50-member team; one-year duration, in the automotive domain. Very mature managers and module leads. Excellent architect. Team members were enthusiastic. On-site account management team maintained excellent relationships with the customer. All signs pointing to a great success, right?

Paramu

You are painting a rosy picture, but it is a candidate for our discussion – so something is not going well under the hood. Let me take a guess or even better use the framework.

Let me start with Execution Excellence – this being a large engagements. Does the team have a good understanding of project purpose and business case?

Ananth

Yes. They do. Their current business processes are manual and based on many Excel sheets.  This is the first time they are building custom software for the automotive fuel emission regulation. There is an expectation of reducing cycle time from 18 months to 6 months. The team members are aware and are excited by the prospect of making such a significant contribution to the customer.

Paramu

What about their estimates? Are they realistic? How are they tracking against their estimates?

Ananth

Good question. Fairly realistic. The team is not working on week-ends. They seem to stretch themselves on week-days when there is a deliverable or a demo – but mostly fine. They have also re-estimated the size and effort after design stage.

Paramu

But, are they meeting the milestones?

Ananth

By and large – yes.

Paramu

Does this mean that their planning was good? Given this is a long-duration project, how adaptive is their planning?

Ananth

This has been their strength. They have a fairly high level plan and they seem to be elaborating on it progressively. Refining it as they go. In fact, their approach to risk management got a quarterly award for best practice. All the team members play a role in managing risks and issues.

They have regular reviews and there appears to be continual course correction.

Paramu

Oh, that sounds good. One worry I always had was about the interest shown by the management in the project. Many a time, management seem to be distant. In this project, how engaged is the senior management? Are they participating in reviews?

Ananth

I sit in most of the reviews as a member of the review panel. The Delivery Head and The Centre Head take an active interest in the project. They understand the obstacles and support the team in overcoming those. They bring updates from customer management – anything relevant to the team.

Paramu

Hmmm. Management seems to be engaged. Management also seem to be recognising team’s effort in improving their risk management practices – as you stated before.

Ananth

True. Even the on-site Account Management team briefs the team regularly on project steering committee meetings.

Too good to believe. Right, Paramu?

Paramu

Too good, alright – so far. Let us explore some of the other vital signs. How is the team’s connect with the customer?

Ananth

Anything specific you are looking for?

Paramu

How is the operational connect – you know the regular sync-ups on project status at all levels?

Ananth

The feedback from the on-site Account Management team is pretty good based on what they are hearing from the customer. Last CSAT – the team got 5 out of 5 on all the parameters.

Paramu

What about change management? A project of this duration with the regulatory flavour is likely to have requirement changes flowing in.

Ananth

You are quite right. The management had anticipated this and has put in well-structured change management practices in collaboration with the customer. Seem to be working fine. Impact of changes are factored into the plans and disseminated to teams religiously.

Paramu

Continuing on Customer Connect vital sign, here is another good one – Product and business domain insight. How is the team doing on this front?

Ananth

I must say that the team has struggled to stay on top of this one. There are specialist BAs on-site. While they understand the automotive industry, there is limited experience with emission regulation subdomain. They have been attending relevant seminars and have connected to various industry forums.

The real challenge has been to get the broader team gain adequate knowledge of the domain and seeing beyond the words in the requirements specifications. Having said that, the team has been growing in confidence over a period of time.

Paramu

Yeah! This could be the Achilles’ heel of the project.

Now this leads to the next vital sign – Engineering Excellence. There is a manifestation in the framework that goes like this – ‘Adequate domain expertise exists in the team to understand the intent of the product requirements’. Where does the team stand on that?

Ananth

The keyword in that manifestation is ‘intent’. The team understands the detailed requirements enough to translate them into a solution and demo to the customer. However, their understanding of the intent is questionable. The trouble with this challenge is that the failures will show up when the system is tested for broader real-life scenarios. Issues will not show up when functions are demonstrated in isolation to the customer.

Paramu

Great insight – without the framework this aspect may not have surfaced. How are the other engineering practices in the team?

Ananth

The Team had robust verification and validation processes. Excellent capability in design, development and testing. Pro-active automation for build creation and testing. However, some key problems were lurking behind this wall of good practices. You are in some way blind.

Paramu

If they had robust validation processes, how did the issue not show up during customer demos and acceptance?

Ananth

Excellent question, Paramu. This is where you need to understand the project context. The current system was manual and relied on multiple Excel sheets. Some of these Excel sheets had implemented complex models with a zillion Excel formulae. The validation process involved comparing the output of the software with the output of the Excel sheets. The team members knew the internals of the Excel but did not know enough to speak user’s language. Therefore the true intent of the user was lost.

The team members and user representatives had an excellent rapport. They tolerated ambiguities and kept moving forward under time pressure. So, the validation process lost its effectiveness and the demos and acceptance ended up being a bit superficial.

Paramu

Wow. How does a quality assurance professional or a reviewer figure this out?

Ananth

Another excellent question, Paramu. Our framework will not be useful for what I call ‘Armchair quality professional or a reviewer’. Knowledge of project context and understanding of the people dynamics is critical for successful assessment. We were lucky to have an excellent quality professional for this project. She would attend demos, sit in team meetings, be active in project reviews, connect with team members, etc. She genuinely wanted to help the project succeed and the Project Manager saw her as an ally.

Paramu

Now – I am really curious. How were the issues addressed? Was the project finally successful?

Ananth

The project team did not have the advantage of our framework, Paramu. They did realise the issues before delivery to the customer but it was still late. They needed a lot of corrective action and the project was delayed by a couple of months. Was it successful? I would say, ‘yes’. The stakeholders were happy with the solution in the end and customer’s management appreciated the pro-activeness of the team.

Paramu

That was a good scenario. Let me summarise

  1. Project health is multi-dimensional – all the vital signs are important. Components of one vital sign can influence a related component of another vital sign.
  2. Weakness in one component of one vital sign is enough to derail a project.
  3. Understanding of the project context is vital for successful assessment of project health.
  4. An assessor, e.g. a quality professional, needs to participate in project activities and be an ally to the team.

Ananth

Great summary, Paramu.

Click here to see Part 3 of the discussions