The key to the health of a project is the implementation of good practices. A ‘healthily’ developed product is a product where good practices are implemented at all stages during development. A product that is developed through a project that is healthy at all stages always assures positive outcomes. The recipient of the product is also assured that the provider (the developer of the product) can repeat this success in future product development. Internally sensing the true status of a project, at any point in time, will help project managers apply corrective actions where needed and steer the project on a path of continuous improvement.

A framework can be developed grouping these practices into ‘vital signs’. These then can be used for assessing the health of a project. Like the vital signs of your body, the heart rate, the blood pressure etc., at any stage of your life, can indicate how healthy you are, to know if a project, at any point in its lifecycle, is healthy, you have to look at its vital signs. If these vital signs are okay, it means the project is healthy. It means that you are assured, at that point, of positive project outcomes.

The six vital signs of a project are:

  • Customer Connect
  • Goal-Focused Team
  • Engineering Excellence
  • Execution Excellence
  • Engaged Management and
  • Continuous Improvement

The question is how do you extend this concept of vital signs for assessing the health of a project to programs. What are the vital signs of a program?

Read the following extract from our upcoming book, Software Project Health: An Epic Retold, looks at this:

Arjuna, the manager of a large program – developing the systems for the defence and security of the country – was feeling thrilled. Over the last couple of months, he had detailed all the necessary health indicators or vital signs of projects. He now could forecast the outcomes of all the projects within his program whenever he chose to do so. Also, if his customer at any time wanted to know how the projects where progressing, this framework of indicators or vital signs could be applied.

His elation showed when he next went to meet his coach, Krishna. Krishna was meditating in his office when Arjuna walked in. His meditation disturbed, Krishna opened his eyes and looked at Arjuna.

He said, “You seem to be in a great mood today.”

“I am. I have finished detailing out all the vital signs of a project.”

Krishna smiled. He said, “Well, you are young. Yes, you may have detailed out all the vital signs of projects. You can now assess the health of the projects within your program.”


“But, what about your program itself? How will you know if the overall program is healthy? The customer finally will judge the entire program, not individual projects. How will your management and the customer assess the health of your program?”

Arjuna’s face fell. “Oh, my God! I had not thought about this at all.”

“Don’t feel depressed. It’s okay. Not many people can think about the situation they are in from within.”

Arjuna asked, “What should I do?”

Krishna asked, “Arjuna, tell me. You have led programs before. What is the difference between a project and a program?”

Arjuna said, “I have only led smaller programs before. But, what I know is that a program is a collection of projects working towards a common goal.”

“Is that all? What did you do as a program manager?”

Arjuna thought, “For one, I coordinated the work of the different projects under the program.”

“Okay, what else?”

“I ensured that the interfaces between the projects are articulated, designed and implemented properly.”

“Good. And?”

“I ensured that the products developed by the projects presented a common front and interface to the outside world.”

“But that is only if the program is delivering a single integrated product. It needn’t be so. The program could be delivering a suite of products. Why was the program called a “program” and not a large project?”

“I think it is because the program did not end with the delivery of the product. It was ongoing.”

“Good. But, why was it ongoing?”

Arjuna thought, “I think it was because the customer organisation’s strategy required certain outcomes and the product developed by my program had to support realizing these outcomes.”

“Exactly. You have got it perfect. A program is aligned to an organisational strategic objective, unlike a project which delivers logical parts of what is required to meet the objective.”

Arjuna said, “Now that you say it, it makes sense.”

Krishna said, “Yes. In fact, I was told that you had the makings of a great program manager. You only had to learn the terms!”

Krishna asked, “What else did you observe about the program? How was your interaction with the customer?”

“We had to prove to the customer that the product delivered was helping the customer realise the advantages due to the strategic objective.”

“Wonderful. You mean you had to manage the benefits delivered by the program?”

“Right. Benefits and RoI management was the key thing.”

Krishna said, “Let us look at your program and see what the benefits to be delivered are.”

Arjuna said, “Well the benefits are:

  1. Reduce illegal entry into the country by 95%
  2. Increase by 35% customs duty collection from traders entering the country with goods and leaving with cash
  3. Deploy defence shields in under three seconds and ensure people are in bomb shelters in under one hour, if there is a threat of an attack from the enemy.
  4. Launch missiles in pre-emptive strikes against enemy missiles at a far enough distance from the city
  5. Protect computers and communication systems from cyber warfare by enemies
  6. A centralized command centre for monitoring and triggering actions across all systems and interfaces to ensure coordinated high-impact actions in time with zero collateral damage”

Krishna said, “You can see how these benefits are different from project goals which are to deliver required software to specifications. You can also see that that benefits can be delivered incrementally and not only as big bang at the end.

He continued, “For example, you need only deliver one of the projects under your program for the first and second benefit realization (with interfaces to the customs duty collection at the gates of the city). Cybersecurity is also more or less independent not too much coupled with other projects, though they are all parts of the integrated program. So, benefits 1, 2 and 5 can be delivered and realized ahead of other benefits.”

Arjuna said, excited, “But benefits 3, 4 and 6 are closely related (peril detection, action – proactive and defensive and coordinated response with no collateral damage) and hence the corresponding projects need to come together to deliver.”

“Exactly. You catch on fast!”

Krishna continued, “Of course, there are other areas also that matter. For example, stakeholder management.”

“But, the program stakeholders will be different from the project stakeholders?”

“Certainly. You are dealing with a higher level of stakeholders. Stakeholders who are looking at delivering and achieving strategic objectives and looking at benefits.

Krishna continued, “In fact, as a program manager you have to think big picture; think customer strategy; think stakeholder benefits; think relationships, and think vision and leadership.”

Arjuna asked, “Won’t risk management also be one of the areas to look at?”

“Yes. It would. However, you need to clearly distinguish between program and project risks. As a program manager, you should be concentrating on managing program risks, leaving project risks to the project managers.”

Arjuna asked, “And how would you judge whether a risk is a program risk or a project risk?”

Krishna said, “Very simple. Ask yourself these questions: Is the risk affecting RoI or benefits delivery? Is it affecting organizational strategy delivery? Is it a risk based on market / environmental factors? Is it affecting project output integration with system? Is the risk affecting financial performance? If the answer to some of these questions is yes, you are probably dealing with a program risk and you should be up in arms against it.”

“Okay. I now understand. And in a similar fashion, I can manage program change too?


Krishna continued, “And as the person managing benefits, you should be more aware of the financials of the program than a project manager would the financials of a project.”


Krishna continued. “The next area is the actual program lifecycle management.”


Krishna said, “Program lifecycle management has to be flexible, adaptable and responsive. It is implementing the areas of strategy alignment, benefits management, and the other areas we talked about on an ongoing basis.”