What is success?

7 comments

I think that thetopic is certainly something that has and will continue to be disucssed for many moons.  On reading the posts we are all saying similar things in that it is about the customer 'perception' of success / benefits / value that is important.  The technical delivery of time/scope/budget is what we should be doing anyway, although can often present major challenges on any project.  But as we have said it is what the customer sees as successful, the legacy of the project is that is should have made a positive difference otherwise why start, but more & more challenging for PMs is the stakeholder mgt required to ensure that the perieved success is acknowledged.  Good strong technical skills, with very strong people skills, listening to what the customer really needs / wants and delivering that, is what we are about - changing the status quo for the better until it needs to change again!

I'm encouraged by several of the comments here.Some 'benefits' that I have seen from some supposedly successful projects are way off the mark simply because the outcomes, benefits and underlying needs of projects' customers have not been properly determined and envisaged in the first place.  (And is this more likely to be the true within the public sector?)So, this is mainly a Scope problem, and it's a difficult call, particularly over a long term; many people involved in projects have learned to guard against dreaded scope creep, but it's in no-one's interest -except anyone whose 'success' simply = sticking to the plan- to fastidiuosly keep to scope when circumstances and needs out there in the real world have changed.Darren in particular mentions harvesting knowledge from projects, and for me the success to an organisation delivering a project, and that will rely for its future on delivering many more, is largely about the (learned) ability to keep on learning and so improving what it does. How well does the organisational culture and environment, which houses and must support project delivery teams, provide established yet open opportunities for PMs and others to share what they're doing, how they do it, what they've learned, what frustrations they might have in common and repeatedly need to overcome, and that some might have found solutions for....?Very briefly this includes1. providing, maintaining and embeding channels for rich communications and sharing, and2. giving clear messages that(a) exchanging knowledge in this way is a legitimate way to spend your time at work (!); it's actually better for business,(b) senior managers of the organistaion lead by example in championing these practices, and(c) TIME is factored in to allow for this - it's not just a race to the finish line, then a break-neck turn-around and a race to the next start line.If this does happen well then that counts for me as success.And getting our own houses in order will ultimately provide our projects' customers with better results.

From my experience, it doesn't matter how well as a project manager you have managed and achieved your scope, timeplan and budget if the stake holders don't feel you have delivered what they actually set out to achieve as a business in the first place.I work on capital equipment projects in high speed packaging for food and beverage, and quite often at the concept / feasibility stage the original scope changes as market interogation and supplier capability are realised.A key thing for me is tying down the scope, then achieving and maintaining buy-in from stakeholders at every stage gate until the project is finally handed over.I have in the past worked on projects that have been seen as successful by the project team but then 6 months later are considered a failure by the end users as the project deliverables do not match the same deliverables as the production / engineering teams.  This is why it is dangerous to base project success on scope, timeplan and budget.Obviously the three 'holy trinity' are all key deliverables for a project manager / project team, but I strive to look beyond the natural life of the project itself to ensure that a legacy is left behind that all those involved can be proud of.In short, it's the legacy that matters.

We in the project management community are only too aware of the project success question. It is something we face everyday and typically we find ourselves succumbing to the triple constraint the unholy trinity of project management. Scope, Budget, Time. Thats it. Do each of those and you are a god amongst men, a guru of unparalleled skill and a champion of champions.  There is one problem. No-one knows how you did it because you didnt harvest the knowledge from the project, your staff are none the wiser because you didnt develop them, the team think you are hopeless because you didnt lead them and the customer would rather sleep in a bees nest that spend another day in your company because you didnt engage them.  My doctoral study; Greater Expectations explores the issues surrounding organisations. The fact is we have greater expectations of them and they of us. It is not enough to do something, its about how you did it.  What is a successful project? In my humble view, it is a project which was tied to the business strategy, had support throughout the organisation, was scoped appropriately and delivered to that scope, was funded and costed correctly and delivered to that budget, was correctly planned and delivered to that plan, maximised value whilst reducing risk, harvested learning throughout the lifecycle and developed the project team with that knowledge, was led by an inspiring project manager who engaged all those involved.  Its not much to askis it? 

A decision is made to invest resources into a project based on projected benefits that will accrue and these are usually defined in the business case for the project. Project success is therefore meeting this business case and ensuring realisation of the benefits that the project promised to deliver and were used as the basis of embarking on the project.Even if the initial time/cost targets are not met, these can change over the lifetime of the project but as long as the business case remains valid and at the end of the day the promised benefits can be realised, the project should be regarded as a success.IMO, the challenge therefore is ensuring a consistent view of what constitutes the benefits that are going to be be derived by all the stakeholders.  

On time and on budget are legitimate drivers if you are working on a fixed price contract as the contractor. For every other project time and cost are largely irrelevant, what matters is realising value from the investment in the project.  And value itself is multifaceted, financial value is just one rather limited aspect. If time and cost are really as important as project mythology makes out, every time you decide to take an important person out for lunch or dinner the choice would be between McDonalds and Wimpy they are both low cost, very quick and meet most of the elements of quality.  If you chose somewhere else for the meal you are prioritising a different set of values you will spend more money, it will take longer to get served and the food is likely to demonstrate significant variability. The value realised has little to do with speed, cost and uniform predictability.  Unfortunately whilst very few senior executives chose to eat a quick burger as a meal of choice, they seem unable to translate the same approach to realising value into the project arena. In fact it is only in the last couple of years people have really started talking about benefits realisation (unfortunately with a bureaucratic fixation on east to count benefits). This is not a project management problem project managers are paid to achieve the objectives defined for their project and respond to the environment created by senior management. The problem of realising value is a senior management issue in first setting the right objectives for the project, and then following through after the project has delivered its outputs to ensure the organisation changes so it can realise the intended benefits and generate the value promised in the business case. For more on this see: http://www.mosaicprojects.com.au/WhitePapers/WP1023_Benefits_and_Value.pdf

I've been goading my current organization into debating this. Comparing Wembley Stadium (as above) to the UK Passport project, I believe it was, that came in under budget, on time, and apparently to specification - was hailed as one of the most successful recent Govt projects - and delivered a flawed system ... Surely the bottom line has to be: Did it deliver (or exceed) the expected business benefit, within acceptable time and cost?