I got client requirement now i want to design strategy and criteria to measure success and failure of project please help me to do this actually i m developer now i got work of project manager so please help me ..


Ultimately, the project is only a success if the client thinks its successful. Ask them what "success" looks like for them. Then keep asking them over the course of the project.

As you deliver work and work together, both you and the client will learn more about the project and the final product. "Success" can change over time. Make sure you and the client stay on the same page throughout the process.

If the client is not happy at the end of the project, saying that you met all of the requirements isn't going to change how they feel. That's why its important to keep the relationship and communication going throughout the project.

  • I would add one caveat to this Mark - If you're going to continue to re-define success as the project progresses, then you aslo need to make sure that you have a rock-solid change control process in place. You have to at least start each project with some formal agreement on what success looks like. Then you can adjust as you go, using proper change control. Otherwise you have uncontrolled scope creep. Mar 19 '12 at 15:52
  • Thanks, Trevor. That's an important point. I'm thinking more of an Agile approach where you are both working towards features and functionality that add value rather than against a pre-defined requirements document. It would only be scope creep if you are working against a fixed requirement doc. You do, of course, need the right type of contract in place to make sure it doesn't become a big money pit for the developer : ) Mar 20 '12 at 19:05

From a purely practical point of view, start by taking a blank sheet of paper and writing down a list of criteria which you believe will define the success if the project. Make sure that these are at the right level, such as:

  • The project is delivered by (date);
  • The total cost is no greater than (some number);
  • The project meets its funtional objectives, as agreed by (named person);
  • The system passes non-functional test criteria: performance, security, resilience, (list these in whatever level of detail you can).

There may be others, around delivery of benefits, or company image, or integration capability, etc. Get them all down, but take care to be realistic. Then present these to the person who is commisioning the project, and ask for feedback. Hopefully there will be agreement; more likely there will be changes required. Either way, you have made progress towards an answer to your question.


While there is some debate around this, I suggest to clearly separate product success with project success. In my view, there is a clear demarcation line between the two, with different roles having accountability of each.

The project sponsor gets to define the weight of each of the criteria in terms of what is more important to him/her. No two sponsors are a like and each has his/her own tolerances.

At the highest level, a PM is delivering scope that meets requirements against target dollars and against a target period of time, which is nothing more than the project triangle. Because there is variability in everything we do, each of these goals has some level of tolerance both favorable and unfavorable. From here, break these down into lower level objectives, ensuring that each lower level objective maps directly to only one of the three goals and that is supports it.

Product success criteria should be established in the business case, which is developed by the project sponsor and organization. It is not your concern as the PM. Whether or not the product does what it is supposed to when they developed the case is irrelevant to you.

EDIT: Iain9688, your example is a good one and I think, at least from my point of view, displays the ambiguity of role accountability that we often see. I'd make a case where there are two roles at play here with two different sets of accountability: a PM who is responsible for delivering the system and redesigned set of business processes that show efficacy at least through simulation; and, once done, an Operations Manager--this is a retail store, an ongoing concern--who would take ownership of the capability for continued improvement, monitoring, adjustments, etc., to eek out the overarching business goals.

  • Arguably, the project could be to deliver product success, so it may be an artificial split. Ultimately I believe that the Project Initiation Document (or equivalent) should define the success criteria.
    – Iain9688
    Mar 16 '12 at 12:35
  • I don't know what that would look like. Product success is a dependent variable. You control the things that would increase the likelihood of its success, but not the success itself. I think that is out of scope of a project. Mar 16 '12 at 18:34
  • It's an interesting point, David. One of my projects was required to deliver savings in a retail (convenience store) environment, and in particular reduced stockholding costs. The system had the capability of delivering these savings, but my project was wider than just implementing the system: I was also required to deliver improved business processes that would bring our average stock levels down to 5% below the industry average without impacting order fulfilment. So in this case, I was required to deliver business success (i.e. product success) as well as project success.
    – Iain9688
    Mar 16 '12 at 19:47

The project's success or failure depends on the degree to which it meets the requirements. Note: no extra points for gold plating!


First of all I confirm previous answers, that most important is to have defined and confirmed by client, the success criteria of the project. The criteria can be divided into mandatory and optional - nice to have.

When changes requests arrive during the project, you have to carefully evaluate the impact on success criteria, and/or receive client acceptance to criteria changes.

However, above will grade the project as seen in black and white, ie. success or failure. But in reality, there are also other situations....

You might consider to define KPIs (Key Performance Indicators) of the project success, which are based on above mentioned success criteria. For example exceeding budget by 5% might mean only minor failure, but by 15% as critical failure, which might carry serious consequences. Similar KPIs might be applied to schedule and quality.


There are multiple types of success - that of the development team, that of the organization building the software, and that of the organization paying for and/or using the software. Each of these successes are also independent of each other, as well.

The success of the development team is often technical success. It might be building a system that meets the operational requirements, both functional and non-functional. It might also be building a product with a low number of defects. Or it might be overcoming some kind of technical challenge and building a type of system that has never been built before (either by the team or ever).

Success in the eyes of the developing and/or sponsoring organization are often business successes. Although they want a high quality product that meets requirements, they also want a product that is delivered on time and on budget. Budget and schedule overruns (depending on the amount of overrun) are failed projects, while achieving goals or beating goals are successful projects. In the eyes of the end recipient, there's also the concepts of value-added and return-on-investment that might be used to judge the success of the project.

Although it sounds like you're probably more interested in the business successes in terms of adding value, maximizing return-on-investment, and meeting budgets and schedules. These are addressed in David Espina's answer and Hubery Chylewski's answer. However, no answer addresses the technical success factors. Even if a project fails from the business sense, there could be technical successes that help other projects succeed.

A good example of this is in Robert Glass's Facts and Fallacies of Software Engineering. A project overran schedule by 200% and budget by 400%. From a business perspective, this project failed. However, the development team delivered a low-defect product in a technically challenging environment, and therefore saw this as a successful project. In addition, if the developing organization acts on their lessons learned for future efforts, the reasons why the schedule and budget overran can be prevented, making this an investment for future efforts to improve organizational performance.

My point in all of this is that, in addition to setting business objectives, any measure of project success should also contain inputs from other people, from engineers to quality assurance to support staff. When you conduct your postmortem, be sure to consider all of your measures of success when analyzing the project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.