A victorious army opposed to a routed one, is as a pound’s weight placed in the scale against a single grain. — Sun Tzu
While I won’t compare weights and measures of ancient China (the “I” and the “SHU” versus the pound and the ounce), I will measure up Sun Tzu’s comment against the weight of managing a successful project. All too often projects are focused on the future. The drive for success is what becomes important! I have fallen into this habit myself, commonly chanting a string of queries: “Where are we at?” “How are we doing?” “What will it take to get us to ‘done’?” These are the core questions for status and moving forward. But what about celebrating our successes?
Like a victorious army, a project team which is in a state of accomplishment, recognition, and celebration for what they have delivered will be more successful than one which plods along unsung and unrecognized. One may even think of this very basic human behavior (the need for attainment and acknowledgement) as one of the drivers for moving toward Agile methods. In terms of short sprints and delivering useable widgets on a regular and recurring basis, the Agile project team and its stakeholders feel a sense of success that is repeatedly reinforced.
I have no beef with Waterfall methods. In fact, I am more comfortable as an “old dog” working in this mature framework. However, as you find yourself working in a more structured phase-by-phase approach to meet the needs of the project, ensure that milestones are built into the plan, recognized, and celebrated.
Too often, project teams reflect on their successes (or missteps) only after the project has been completed. The infamous “Lessons Learned” (or more aptly named post-mortem reviews) are often touted as a key for improving one’s delivery. However, too often these reviews are not conducted. The project is over; the team has disbanded; the next project is underway and there is no time. But even if the reviews are conducted as planned, with all the appropriate participants engaged, is it just too late (citing all the reasons that the reviews may have been skipped)? The project team will soon disband. The product, widget, service has been delivered. The project is being closed and the next one is starting up. There is no time! This post-project approach assumes that the lessons learned will be documented, studied, and brought into the next project. Isn’t this just missing the opportunity for an in-process review?
If instead of waiting for the project to end, should we structure our projects with meaningful milestones that demonstrate accomplishment, that enable us to celebrate our successes along the way (and learn our lessons, good or bad)? I don’t mean typical project milestones that come at the end of a phase — although some phase gates should be celebrated milestones. What if we were to embed milestones into plans that are measurable and worthy of recognition? So, instead of achieving the temporal milestone of “Requirements Complete,” one could instead aspire to a milestone that was more accomplishment oriented. “Accomplished documentation of requirements for CRM in all global regions.” That sounds like a much bigger achievement than “Requirements Complete.” We don’t need a party, or a bonus paid out to all milestone contributors. But a pause to reflect on how we made our mark — presumably on time and within budget — offers us the opportunity to stoke the energy of our team.
The point is simply that there is an enormous advantage that a “successful” and celebrated project team can have over a team that has seen too much time between recognized increments of success. Take the time to acknowledge a job well done for defining the requirements and meeting a critical milestone. The more often we find reasons to declare and celebrate successes, the stronger our teams can become.
