Ownership and Initiative: Victims and Vanquishers at the End of a Project

by Cinda Voegtli, ProjectConnections

In previous articles I've talked about the difference between victims and vanquishers. In the face of tight deadlines, changing project requirements, resource conflicts, technical risks, and so forth, vanquishers understand the role they can play, the influence they can have. "They speak up, identify problems, suggest solutions, take a stand on tough issues, make things happen—and participate from the beginning to help the team avoid problems in the first place." Vanquishers are highly-valued team members and highly valued throughout the company.

Let's talk about what this might mean at the end of a project. How is it possible to be a "vanquisher" when the project is just about done?

The end of the project is actually one of the most critical times for vanquisher behavior—less for your project specifically, and more for the benefit of your company overall. A vanquisher mindset now can significantly contribute to the success of the projects that will come after yours.

To illustrate what I mean, think back to typical project problems. For instance:
  • The company decided to use an outside development house to help get a new product out the door quickly. But instead, perhaps that group misunderstood the specifications, or didn't really commit to your end date, or delivered an untested, buggy product to you. These all-too-common real world occurrences on "partnering" projects usually result in painful delays and recovery work.
  • A software project's schedule got derailed during the design phase, when it became apparent that there would twice as much coding to do as previously thought. The result may have been panic efforts to assign new resources to try to hold the schedule, abandonment of some features to hold the schedule, or slipping of the end date to allow the extra work.
In each of the above scenarios, what was the underlying cause of each problem, and what would that team do differently the next time? In the outsource instance, was the outside development group not savvy about your type of product? Would more detailed specifications, or co-locating the developers, have solved the problem? Would you write a more stringent contract to enforce delivery dates and acceptable levels of testing? Or would you handle vendor selection differently next time, and not even select this particular group?

In the software example, were all the modules identified, but their complexity or size estimated poorly? Or were some modules not even identified during the early design and planning stages? If the latter, was it due to poor architecture work? Lack of detailed interface definition? What would the technical group do differently next time to avoid this late surprise? Have more or different people participate in estimating the work? Do more detailed architecture and interface specifications? Hold better reviews?

In your company, do these questions even get asked? Or is the next project likely to suffer from the same problems as the last project? What role can you as a vanquisher play to ensure that doesn't happen?

The answer: at the end of a project, the vanquisher is already thinking ahead to the next set of challenges, and preparing to meet those challenges head-on-with appropriate avoidance techniques wherever possible. Your greatest contribution at the end may be to have your team ask those important questions! For instance, you can hold "post-mortem" or "post-partum" or "lessons learned" meeting. This is a forum where your team members would come together to capture and analyze what they've learned on this project. What were the challenges? What was their impact? Conversely, what things went well, and what were the related "best practices," worth repeating next time? What lessons did the team learn, what recommendations would they make to future project teams? The results of these meetings should be captured in a report or a database and made available to everyone else involved in the company's projects. No mistake should be repeated, and it's worth investing the team time in this analysis to make sure! You can make sure that happens.

So think about the lessons your project has learned, and who in your company should know about it. Be the one who insists on holding a "lessons learned" meeting. Make sure the results get copied to other engineering managers and project managers. Post them on the intranet. Remind people to look at them, at the beginning of their projects! Your initiative now can set the stage for significant success on projects that are just beginning.

Vanquishers get listened to, appreciated for their maturity, promoted, and given the best opportunities on the next project. It can and should be you!

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy