A recap on my series of six blogs around project scope. Includes links to slide deck and customizable templates:
1 of 6 — Scope or: How to manage projects for organization success, part 1
The ability to deliver a project is the ability to compete. Scope kills projects and projects that are not delivered kill organizations. Scope is one of the most important ways to manage project success. And when projects succeed, organizations succeed.
2 of 6 — Scope or: How to manage projects for organization success, part 2
The key for organizations to grow and to thrive relies on how to manage projects and how to manage projects for organization success becomes an industry competitive advantage. But why do so many projects fail?
3 of 6 — Scope or: How to manage projects for organization success; impact analysis template
An impact analysis unearths the layers and levels that the change will effect. Just like tossing a pebble into a pond, projects cause ripples that are carried far beyond the initial splash.
Link to download Impact Analysis Template – fully editable Excel .xls file via Amazon Web Services
4 of 6 — Scope or: How to manage projects for organization success; stakeholder analysis template
The only way to manage projects for organization success is to identify and manage the stakeholders that the project impacts. A stakeholder is anyone [or any group] who can positively or negatively affect the outcome of the project.
Link to download Stakeholder Analysis Template – fully editable Excel .xls file via Amazon Web Services
Link to Stakeholder Analysis matrix, tab 2 – fully editable Excel .xls file via Amazon Web Services
5 of 6 — Scope or: How to manage projects for organization success; communications template
Without communication projects become a public relations campaign and change management relies on hope. Plan for the portfolio, the program, or the project and all the workstreams, channels, and measurement of impact with the a proper communication template.
Link to download Communications Template – fully editable Excel .xls file via Amazon Web Services
6 of 6 — Impact Analysis — project management SharePoint template
The past year I modified the above suite of project templates from Microsoft Excel to Microsoft SharePoint, an integrated collaboration and publishing tool.
SharePoint is a great collaboration tool to improve project management experience. I now offer the old set of Excel scope templates to anyone using SharePoint, as well as new opportunity register and change management tools within SharePoint.
Impact Analysis Template for SharePoint
Share this Post
Comments 5
Hi Toby, this post represents a substantial intellectual effort. There’s one thing (you would probably appreciate) I simply can’t agree with, that is the references made in relation to project failure rate. The numbers quoted are unrepresentative of reality and should not be used as a scientifically accurate measure for projects’ success.Cheers, Shimhttp://www.quantmleap.com
Project success, I guess, can be subjective. If we hold the team project success to mean a project a project delivered on time, on budget, and within scope, then we begin to separate the difference between getting project success with project failure.One thing I learned, so far, is people who demand data are never satisfied with data. I’ve really enjoyed our dialogue across your website and Twitter.
I’m going to save a detailed reply, however, for a bloated blog I have been working on about that goes into the data to support my concern that the majority of projects fail – bear with me, please.So, on one hand I can’t get drowned in data, because, as I’ve pointed out on your blog, quantmleap, confidence intervals, control groups, statistical validity can not be replicated in a scientific environment to prove project success/failure.
You are correct, the factors will not allow for scientific validity and repeatability. But why, then, do I use data to support the project failure rates? I convey data in this realm because the amount of project sponsors and stakeholders who don’t bother to identify scope or realize the level of risk involved to deliver on time, on budget, and up to expectation staggers. And if I’ve taken the Project Management Institute’s oath that if the project fails I deserve to be fired, I’m pretty concerned about launching a ready, fire, aim project.I could say, “the majority of projects fail”. But I take it a step further and try to convey to sponsors and stakeholders some industry-specific research by Deloitte or KPMG or IT firm survey’s that bring about a level of seriousness before launching a project.
So, Shim, I am, I really am, putting together the research I’ve had to present a blog on if projects really fail so much. You have given me enough encouragement to provide this type of blog and I think others will find it interesting.
Also, I really enjoy the challenge to make the case.Until then, we’ll divvy it up this way: I’m in the Northern Hemisphere, so I’ll continue to say to Northern Hemisphere folks, “the MAJORITY of projects fail“; you are in the Southern Hemisphere you can say to Southern Hemisphere folks, “the MINORITY of projects fail“.
Thanks Shim, I really enjoy your site and that you keep me honest.
Hi Toby, interesting reply. I’m happy to be patient and await your detailed, substantiated, reply. However, there is one point I need to respond to now, as otherwise it might be seen as if I’ve tacitly accepted them as truths; which I don’t.
It is absolutely possible to gather data regarding the actual rate of projects’ failure. The issue is not with the collection, the issue is primarily with the definition. As I’ve pointed out in numerous occasions the suggestion that for a project to be deemed to be successful (i.e. not a failure) it must achieve the ‘on budget’, ‘on time’ and ‘full scope’ conditions is an unrealistic one, as under this definition 99% of all projects will fail.
How do I know that? It’s because no human endeavor is capable of achieving 100% and therefore to suggest that all three conditions are to be met one would have to provide statistical margins of error and deviation bands within which success would be achieved.
So, to cut a long story short, the problem that you and others are likely to have is in the way you are happy to define ‘success’ and the bands in which this definition is executed. But, I’m looking forward to your respective analysis with the possibility that you would (regardless of how impossible it is :)) to demonstrate that your claim is based on sound data.Cheers, Shim.
I can appreciate Shim’s and Toby’s perspectives. I think Shim’s main point is, “Project Failure” is too vague a term when quantifying the percentage of projects that fail. As Toby said, failure can be defined a variety of ways, failure to complete the project at all, completion of the project, but not within scope, time, or budget. Then, for each of the later 3, there are degrees of failure, 10% over budget versus 500% over budget etc. Basically, it just comes down to defining your measure of project failure (e.g. 50% or more over budget) and then report the percentage of projects that failed according to that criteria. I am of the opinion you would find a preponderance of credible literature that shows a significant percentage of projects fail to a significant degree almost any way you define failure. In that case, I think you can get away with using “project failure” in a generic sense when reporting the percentage of projects that fail.
If you don’t know what success looks like, how do you know when you’ve succeeded? Projects start with the grandest of intentions, but without a real assessment of what the project constraints are (time, budget, etc…) or boundary of what the project looks like when complete everything after the kickoff becomes set for failure by scope creep and constantly shifting set of modifications.
Terms like “gold-plating” are often used to describe project situations where, once the project is underway, just a little is added, a tweak here, a feature there, next thing you know the budget is shot, the delivery date is missed, the functionality is less than expected. It gives the statement, “building the plane as we are flying” a very real application.
The conditions of failure and success should be made before the project is launched. Underway change and risk are carefully monitored and tracked against original budget, time, and scope conditions set in the original criteria.
My goal is to heighten the awareness of how difficult projects are to complete. With a deep background in organization behavior, change, and development I am highly attuned to organization resistance when change (a project) is needed for elemental organization survival. Failed projects cause an organization to grow weary. A constant sense of failure makes the next project a dubious project when the majority of projects never fail to get delivered, a host of projects are abandoned before completed, or other projects are hopelessly dead before being launched.
I’ve tried to scour the research, surveys, and cases to be able to really impact positive lasting change. Have naked discussions with sponsors, stakeholders, and executives to create a compelling case for project rigor. Being in charge of organization transformation or an executive strategy and heading into an organization that literally has their arms crossed with skeptical looks on their face about this latest project they are required to rally their enthusiasm and expectations around makes for an unnecessary challenge for all.
All thing are not equal. Industries do have particular characteristics, but all people rely on motivation. So different industries and different projects have differing failure rates. The point remains credible: a project’s success is unlikely. Without alignment and clarity expect failure.
Thanks for your comment Steve, your perspective if valued.