I’ve worked more than a few projects in my career. One thing that I always find sorely missing throughout many Enterprises is a follow up report of what went well and what went wrong on a project. In other words a list of successes and a list of things to improve. With that in mind I’ve put together the following survey questionnaire for the end of a project. What other items might you add that you’d want to know?
- Is the overall project considered a success?
- What caused roadblocks or stoppages during the project?
- What caused excess work that was unnecessary?
- What processes could be avoided, added, or otherwise changed to streamline the day to day development and operations?
- What could management do to have made the project even easier to accomplish successfully?
- What could inidividual developers do to have made the project even easier to accomplish successfully?
- Were the tools needed to complete the project made easily available?
- Were access, work environment, and other physical assets provided in a timely manner to complete the project?
Please leave a comment or three about what you’d want to find out once a project is complete.
Some other questions to consider are:
* What are some areas that you wished you could refactor, clean-up, etc now the project is complete?
* Were the people you needed to communicate available (via in-person, email, chat, etc) when you need them? If not, was the wait acceptable?
* Where your user stories well thought out? Was there scope creep?
Thx for the comment Elijah: I’ll be sure to add those to the growing list of items. I’m going to put another blog entry together related to the final list I get put together too. 🙂
Project post-mortems are always interesting to me. Recently, I’ve been involved w/ projects that “never end” and we occasionally have reviews of the past “release” or “feature update”, etc. The approach is a bit different than you describe above. Each person is asked to identify something they did that went very well (better than expected) and something that did not go well (or work out as planned). Also, each person is asked to identify what they think was the high-spot and low-spot in the project life. We then each list thing’s we’d do different next time and thing’s we want to repeat in the next round. By making it a person-by-person focus, we end up covering most of the same things you mention, too.
Another couple of items I’d add:
1. Were the written project definition and specifications, if provided, adequate to guide the developers to the desired product?
2. Were the project’s sponsors actively involved with periodic reviews as the project evolved?
These types of questions are fundamental at large corps like Microsoft, Boeing, and other entities that notoriously use “Agilefall” (as some call it). It’s hard to keep these things aligned in large companies were communication is very costly, even with droves of documentation.
I think one of the most important questions is:
– What are we going to do with this information?
Most teams I’ve been on have realized the need for at least some sort of project post-mortem, but I think what differentiates organizations that can learn and evolve is what they do with the post-mortem data. Too often it just goes to /dev/null.
This sounds to me like a post-mortem or a retrospective. This seems like it should happen iteratively throughout the project. In a way I feel like a project level retrospective would almost be redundant.
There might be value in aggregating notes from all the retrospectives that occurred throughout the project. Of course if the project is waterfall then an overall project retrospective would have a lot to offer for future projects.
During what little time I spent consulting it seemed like client feedback after a project is often missing or inadequate.
Especially on a pilot project where an agency is competing with other vendors nobody wants to hear “We loved your work, we’re going with the other guy”. This is completely useless. We’d much rather hear “Your work sucked because…” or “The other guy was better at…” Not providing meaningful feedback to vendors is probably a major contributor to overall poor vendor quality.
Anyway, I have rambled enough. Aggregating sprint retrospectives at the end of a project seems like it would be educational to all involved and add value.
Thx for the comment. It would be interesting if agencies had post project “what sucked” sessions with open minded clients. That would produce some seriously raucous results I’d bet.
I think communication and feedback are good things and to be encouraged. However, it’s a mistake to wait until the project is over to communicate. At that point, it’s too late. Don’t wait until the next project to use what could’ve made this project better. The next project may not have this same issue. If you communicate while the project is going, a few things can happen. Major problems can be averted by doing small corrections early on. Project scope can be modified to meet changing needs. you’ll always know where you stand.
Yeah, I absolutely agree. I wish all projects and leaders starting projects had this mindset. 🙂
I do agree that reviews should be done much more frequently than at the end of a project. I also feel strongly that if a review isn’t done, and a project just goes blindly forward to the end, that’s a major problem.
Continuous communication, with reviews, and also learning from those reviews and making changes to mitigate issues that had been coming up. Trying to make things better is truly fundamental to making things work well and keeping morale up.
Perhaps more on the lines of project management but … When I was a Producer for eCommerce sites, development morale was down (partially due to the amount of layoffs we faced but also) because we were not sharing results of their hard work. To that end I may add to one as one of your questions:
– Did the project meet the business and user needs
As the production AND dev team started to realize what was resonating with customers everyone benefited, we released features that were actually used, not born in a boardroom.
Who would have guessed I would have taken a measurement slant?
hahaa. I like it. Good suggestion. I always dig hearing about the awesome bits of what has been accomplished. Many companies don’t review those things and it really is a pitty. People do a lot of work and rarely get recognized or simple props of “this got done”.
These are all great questions to ask at the conclusion of the project. In addition to asking if the overall project was successful, I would break down the project’s success metrics (ideally determined before project launch) and speak to each of them individually. This will help you determine 1) whether the final project met these success metrics and 2) whether they were the correct success metrics to apply to the project.
Upon seeing the scenario, but before reading the list, I came up with these high-level questions:
– Did we succeed or fail?
– Why did we do that? (here I would apply the ‘five whys’ technique
– What was difficult?
– What was easy?
– How can we improve on the areas where things were difficult?
– How can we maintain the easy things as being easy?
As others have mentioned, the first thing that came into my mind was ‘sprint retrospective.’ Evaluations like this should happen after each sprint and acted upon; otherwise it’ll just be futile.
Great post and comments. I agree that, in an ideal world, two-way communication happens during the life a project. That isn’t the reality on most projects in which I’ve participated (despite best intentions). More often than not, the failures occur from a lack of vision or technical understanding by the sponsors. Then, when they see what has been built, they start the tweaking process and the scope creep begins. I’ve also seen developers sometimes make assumptions and create cool stuff that doesn’t meet the project’s needs. To me, post-mortems are needed to determine – no matter what occurred during the project – how it met the criteria listed above. This is a great collective list!
I agree with all commments that suggested a “continuous retrospective”. In my team we have reviews every Friday. Maybe not formally a retrospective but a place to surface all issues/opportuntites for improvements/changes. And event though we do have format “start” and “ends” for a project, we moved to a almost continuous stream of content delivery.
Something important, I believe, is the focus on the improving the output of the work, rather than creating a blamefest environment. (e.g. “I needed X because…” as opposed to “Z didn’t provide X in time…”)
Also, my own experience is that you sometimes need to challenge even the things that “work well”. I encourage thinking out of the box and trying new things out constantly. Assumptions are dangerous things that can create a false sense of security. “Nothing is carved on stone”
my 0,02 of course.
I like the “nothing is set in stone” and challenging even things that “work well”. Those apply to pretty much everything.
I also am a HUGE supported of getting rid of the “blamefest” environment. All that ever seems to do on projects is kill morale, and send projects down the proverbial toilet. Good to keep things on the up and up, positive, and focus on the accomplishments and how to improve and maintain solid, usable, and rockin’ accomplishments! 🙂
I have to agree with Jeff that I, too, agree with most the comments.
What might be new information is that there is something about the survey wording and structure I would encourage some thought around: Could the present tone and point of narration influence the results such that they are skewed from the respondents’ true motivation and intention of response?
For example, most of the questions are asking people to speak to the duties, functions and roles of others on the project. This, more or less, forces people’s thoughts in a direction away from their own participation in the project.
It is easy to loose valuable legacy information – especially with the way teams have evolved under the “disruptive innovation” model (people’s roles and functions coming together much like white corpuscles to resolve, disband, and move on to the next project or effort where their skills are required)- from work groups on projects.
No one is as much the specialist about what they did on an assignment as the specialist assigned. And none of the project sections has the overview that the PM does.
Let the individual areas tell their stories. Let them say what they felt they could have done different within their own areas, so they don’t have to speculate or talk about someone elses dirty laundry
If the two way communications processes are in place from the go, it instills confidence. Much like being able to trust that the rest of your team mates are in position and know the plays, leaving you to focus on what you are trained to do. Then,if there is an area, where the group from another section of the project falls short on communications or other issues, that group will be more likely to claim it and describe what the needs were. In other words, shift focus to requesting suggestions on how people felt they needed adjustment in their own areas.
Also, perhaps look again at questions two through four. It almost feels that theses questions could be consolidated, but that the category they address is still nebulous. Bring some precision to where you want those three questions to go.
For example, excess work is unnecessary. And processes that could be avoided, added, or otherwise changed to streamline are roadblocks.
Think for a minute of capturing the lessons learned from projects as a Christmas tree – the tree is a bare and recognized structure for an event, that everyone understands. Then, people decorate with what they want to see on the tree, and place those decorations where they want to see them. It represents the group when it’s decorated. When you look at it, you can be confident you received information they wanted to impart, that was important.
Great points Teresa! Thanks for commenting.
I had not really thought about it, but you have a great point raising the fact that often the questions speak to the duties, functions and roles of others and don’t particularly face inwards as they could. It could be helpful to take an inward approach before looking at the cross team roles, functions, and duties. It might prove to have valuable changes and insights by doing so.
An addendum to #7. What tools could have helped?