How to define the project is succeeding or is it time to put a big cross over it? Do we need to consider this while planning? How to define kill points and success criteria for the project?
Hey Crizpers, today we are going to touch base on the project progress analysis and measurements that we need to judge against while analyzing the project success of failure. Obviously, we do have KPIs that we are tracking regularly. However, what if there is a possibility that KPIs are fine, but the outcome is still not satisfying? Why does it happen?
Kill or Extol
To begin with, let’s define what are we having on mind while talking about Kill Points and Success Criteria? In general, these are the measurements we are estimating the overall project output. They are triggers we are controlling for implementing a certain action. These indicators differ from the project KPIs, however, we are considering KPIs within these measurements.
Success
As for the Success Criteria, we use it for Quality Management and for the overall project progress analysis. Why do we need it if there is a dashboard and we can just monitor the project state there? We have key performance indicators and can track them regularly. However, we gauge the output not only in quantitative marks, but in the qualitative as well. Here our main characters come in. Success Criteria helps to identify whether a project is a victory and how much have we succeeded against multiple indicators.
No Go
Regarding the Kill Points, this is interesting. It is something opposite to the previous term. It is a disaster criteria that helps to define whether we are at the point of no return. I am talking about the moment when something is pulling a project down that much, so there is no use of continuing the work at all.
Reasons for a Murdering
Again, we are talking about situations that may force us to stop the project. We have already discussed that partially in the previous articles. I would again refer to the prior topic (Stop it Now! When to stop a project and how to activate it back) when we have touched base on the projects with a low performance. This can be considered as a dangerous sign, however, there might be more beacons which demand a certain attention.
Continuing with the disaster criteria, actually this is an important indicator, or maybe a couple of them. The criteria will help to stop timely and to save the funds from investing into the failing activity.
Sample 1
As an example, we could imagine a running project in the IT industry. Let us decide to transfer our data storages from our onsite server rooms to some cloud solution. We are already one step there. And at the same time with our project the company has set up an agreement with a new big customer and now people are planning a deployment of the solution.
Only, the key moment in this agreement is that the customer demands us to have a total control over the servers. According to the deal we should have 24/7 direct access to the equipment. What to do with our undertaking to move to the cloud? Considering all the sides of the situation, most likely we will have to stop the work and maybe even revert the already made changes.
From the above we can understand there could be more dependencies than just a project performance. And the reasons could be either internal, and external for the project. By the way, as you may remember, if the project is not performing, initially we need to measure the current state and to define a reason. We are enabling an alarm when we have found out there is no chance to eliminate the problem.
Are we Succeeding?
Along with the Kill Points we need to have the Success Criteria on hand. This is important as we need to define how much we have accomplished with the project. And again, good performance and alignment with the project KPIs is not always a major indicator of the project success.
Sample 2
For instance, we are developing new features for the web application. The delivery is being executed timely, quality assurance was passed successfully and we are launching our updates to production. However, in a couple of days after the deployment we are starting to get complaints from the users. The issue is in errors and failures of the application and its features. This is happening because the popular browser provider has upgraded its version and many users have the automated updates enabled.
At the same time, the vendor stopped supporting the older versions of the web apps code. This forces products to be upgraded. Our product has legacy code too. We have not foreseen this and have not checked the announcements from the browser provider while the features were being developed. This means the overall project went well and was developed timely and efficiently, however, it became useless after the deployment because all the features and the product itself operate on the old code version. As a result, was the project successful?
Considering the above, not only KPIs are making a picture. While planning we need to think globally and perceive a situation strategically.
Setting up a Plan
Initially, to ensure our project will be not just efficient, but also appropriate, before the project initiation it would be wise to align with the overall company and industry situation. What we need to look into are the possible major upcoming changes that may impact the project in general. Besides, Success Criteria and Kill Points in many cases could be simply different sides of the same coin. And at the same time, they may vary.
No Go Planning
For the Kill Points we are referring to Risk Management and forecasting which risks may force us to stop the project for good. This might be new laws or standards, changes in the agreements, percentage of issues on a project or significant increase of the funds consumption. Enable your hawk eye and grab the magic ball from the underneath of your desk. Of course, strategic thinking, industry knowledge and company situation awareness would be helpful too.
Success Planning
Regarding the project success, we need to define the major reasons why we need this project and how is it possible to exceed the goals edges. As you know we are always aiming for something more than only sufficient. To measure success we need to enhance the suitable solution to the desirable one. For instance, the sufficient result is to launch a product with certain functionality. Then to succeed we need to engage a certain number of visitors within the first quarter and then start earning money according to our business plan. Always keep striving for the better!
Phase Gates
The important aspect is WHEN to review and to analyze the progress. I hope you would agree that only the final review at the project closure is not enough. In this case all the essence of the Success Criteria and the Kill Points would be wrong. Finally, why do we need to reflect about the instances in the end when we already are not able to change anything?
To improve the overall project delivery process I encourage setting up a Phase Gate stage if you do not have it now. Phase Gate or Stage Gate is the intermediate pass point when we are examining the current project state, measuring the possibility of failure or success and judging about the further actions. The appropriate moment would be at a completion of a milestone. Usually buy that moment a number of gaps are being closed.
Additionally, if you are aware of the dated of the major industry of company changes, the Pass Gates could be set up addicting to these moments.
No need to recognize such events as a disaster. On the contrary, it could be a great opportunity for the company and for the team to review the situation and to understand whether we are creating something valuable, or it is a right moment to change the priorities and to dedicate funds and resources to something that is currently more important for the business.
Let me know if you practice intermediate reviews? Do you have additional tips regarding the Phase Gates analysis?
Cheers!