If you take a look at you will see that the author proposes a checklist as a tool for projects. Great. He does not say if it is all inclusive, what kind of projects it is for, and he does not really commit to much, which is why I wanted to comment on it here as I put off doing some light housekeeping. The bird’s next over the fridge should probably go outside, and even though it was a nice day yesterday, the doors should likely be put back on the house.
The below is copy and pasted. It is a list, so if the author min.ds terribly, please just email me and we can talk about it. I have sent you a note.
From http://www.projectsmart.co.uk/project-management-checklists.html
Mr. Vaughan is in italics, because it is cute, and I am in regular bold type, because I am regular, but a bit bold.
Among all the tools at our disposal for managing projects, checklists are perhaps the simplest and most productive means of building consistency in work practices. Checklists are useful in almost every field of human endeavour, and in particular where repeatability and systematic action drive performance. Yet they are still much underused in the planning and managing of projects.
I am not sure that they are so useful except as transient artifacts that speak to an audience ready and willing and able to take value from them.
Here is a high level twelve-point checklist for use during project planning:
1. Have the needs and concerns of all key stakeholders been considered and resolved?
I suspect you know I will say that it is impossible to address all concerns of all stakeholders during planning. If we are planning iteratively, we certainly have a better shot. If we are delivering incrementally, we have a better shot, but to have anything more as a goal is to state something as a goal that will just not be achieved. If you have ever tried to have all Stakeholders resolve their differences before anything gets built, I expect you will either get a few angry stakeholders or have never heard of the Product Owner role.
2. Does the project have an overall approved mission statement defining the scope, schedule and resources/budget?
As long as we know it is going to change, all we can really have at the beginning is a Vision. We can certainly have resources and a budget, but resources change (people get hit by buses, I hear) and I would rather deliver under budget which makes the budget less important as our goal, which will of course potentially change. The epic may remain, but functionality can be phased, shelved, pushed to V2, or any number of things.
3. Has the relative flexibility among scope, schedule, resources and budget been determined?
I am surprised to see reference to what sounds like a Tradeoff Matrix here. Most of the time, however, in my experience this is better done as you go than up front unless you are following a Faceted Feature Analysis approach (and there are better ways to Prioritize, I think).
4. Have all project deliverables been identified and described in detail with unambiguous completion criteria?
Holy Mackerel. Really? Before we start building? This can be done, sure, but what parts of this have real value.
5. Are roles and responsibilities defined and agreed upon for all project team members?
This also many change, but you do have to start somewhere. I would rather define roles and have people fill those roles as required in something like a Kanban model or a Scrum Team that really works like a team, but Mr. Vaughan may agree.
6. Has an appropriately detailed work breakdown structure (WBS) been created with input from key team members?
BRUF. Muda. Can throw a million buzzwords at this one, but I will just ask if the project after it has been delivered ever even once looks like the WBS when done up front. I am biased and although I have created my share of WBS documents, I look back and wonder why, except that the whiteboard looked really slick and people tended to assume that I knew what I was doing. Throw some compliant UML up there and you are almost untouchable by critics.
7. Has a credible schedule with identifiable critical path and late schedule been developed from the WBS and optimised within the project constraints?
See #6. If you have done this, you have not only wasted time, but you have straitjacketed your product and your Customers or Stakeholders are not likely to be happy filling out Change Request documentation.
8. Have milestones been included in the schedule to track major events, completed phases and/or deliverables and external dependencies?
Milestones are great, but can we be flexible with them? If so, lets do that. If not, lets see what the definition of that milestone really means. We may hit August 19 and hit the end of a “phase” but gotten nothing done unless you take a more Agile approach and do not attempt to be Karnak the Magician or whatever the guy on the Johnny Carson was called.
9. Have workload commitments been identified for each week of the project and agreed to by team members and their managers?
Every day, in a standup, you mean as well as in Sprint Planning or within the pull of Kanban? I like the idea of commitment. I don’t like the idea of Management setting definitive workloads for the developers.You get overworked, under-appreciated, burned out developers that way. Happy employees get more done than disgruntled ones. Some disgruntled ones come to work with a rifle. Yowzers. Still, the rifle does not worry me as much as this seems to be calling for huge amounts of effort and a constant team with constant velocity.
10. Have response plans been developed for the most significant threats to project success?
Risk Documentation. Exposure can change as you go, but a valid response to a high value item once it has been attempted and proved to be very very difficult and to jeapordize the sprint may be to break it down and employ disaggregation it or put it off until the end. Fail fast. Go after the high risk, high value items first.
11. Has a change management process been defined and agreed to by all key stakeholders?
How about talking every day and constantly re-prioritizing, reshaping, being realistic instead of doing a big fat Big Up Front Requirements document that nobody will ever read along with any number of thick unreadable documents that this approach seems to call for?
12. Has the governance structure for the project been established with an agreed sponsorship role and expectations set for review frequency and format?
I agree that you need structure, but words like governance imply a formality and inflexibility that I think you might wind up needing. People take vacation. Even if you do take OOTO time into account, if your Customer is part of the team and iterative work with incremental delivery is your model, it would seem to me that this will work itself out.
One of the features of checklists is that they can be designed to extend hierarchically, such that a sub-checklist could be developed to facilitate any or all of the checks above (e.g. a stakeholder analysis checklist or a risk management checklist).
Uh oh.
The PMI, training firms and PMOs would do well to promote checklists more strongly – project managers like to use checklists; not many want to read through an overweight methodology. And managers like checklists because they improve quality and instil consistency.
Just as it is in the best interest of the Scrum Alliance (just ask Scott Ambler) to create the CSM certification, it is probably in the best interest of PMI and PMPs to cast a spell upon this as the approach you should use. I encourage the opposite. Try different things. If you have only worked for large companies you likely have not seen the amazing things that can happen in small, empowered teams. Putting people first is in the best interest of everyone.
Thanks for the ideas. Again, the above was a response to http://www.projectsmart.co.uk/project-management-checklists.html. I only disagree to engage in dialog. If all I did was spout what I THINK, I’d be a blowhard. Let’s talk privately or publicly and I promise, if you get me to see things your way I will be happy to have been wrong. It is in MY best interest to be as good as possible.
Best Regards,
Josh