ALL TOGETHER NOW

Ownership and Initiative: Victims and Vanquishers During Development and Test

by Cinda Voegtli, ProjectConnections


When I think about the people I value having on my project teams, I think about the people who know how to make a difference no matter what the circumstances. Those people demonstrate "ownership" of project outcomes, and "initiative" to contribute in different ways to make those outcomes a reality. What's the difference between those people, and those who I tend to peg more as "whiners," people who perhaps give up in the face of adversity or complexity; perhaps don't see it as "their role" to take the lead in pushing past challenges?

I see the difference expressed this way—it's a difference in attitude that then drives very different behaviors. It's the difference between "vanquishers" and "victims." In the face of tight deadlines, changing project requirements, resource conflicts, 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.

To illustrate this in action, consider the design, implementation, and test phases of our projects. What does it mean to be a vanquisher during this time?

The design and implementation phase is usually developers' favorite part of the project. Even when significant technical challenges are present, we can put up with it—we're having a great deal of fun being creative, solving complex problems, bringing a design to life. So it doesn't seem hard to be a positive, enthusiastic, contributing team member. However, hidden pitfalls abound that will trip up victims every time, but give vanquishers an opportunity to shine.

Beyond the normal technical challenges, what difficulties do our developer team members typically face during this time on past projects? How about significant requirements changes in the middle of the project that force them to throw out completed work. Or serious design flaws rearing their heads when developers are almost done with schematics or layout or code. Or test phases executed in a pressure-cooker atmosphere because of inadequate time left for thorough testing and/or an overwhelming number of "bugs."

So what is the vanquisher's role in those situations? Consider these scenarios:
    An influential engineer or an executive walks into the developer's office and requests a feature change that will perturb the schedule and violate the specs the cross-functional team agreed to earlier in the project. The victim-to-be takes every request like this and executes it without question. The later result for him could be overtime to make the change or anguish when the quickly-made modification causes an integration problem with other components. The near-term impact could be disillusionment with the company's requirements process, anger at the executive, and even loss of buy-in to the project's deadline. The vanquisher, on the other hand, understands the importance of the current project plan and how critical it is to not make such changes capriciously. He or she knows that the change could have all kind of implications, especially if it's done quickly. Fast changes often result in sloppy design patches, later integration issues, additional bugs to fix, or unacceptably reduced test time at the end of the project (since the extra time for design changes has to come from somewhere!) The vanquisher would instead acknowledge the person's issue, then raise it to the project manager. The impact on the entire project should be addressed before such a change is taken on-if it is taken on at all. The vanquisher has likely saved himself and other team members significant time and trouble by having the courage to "push back" and help make sure the right decision is made.

    Think back to the most painful project end-games, including testing, that your team has ever experienced. Ill-planned integration efforts where it seemed the pieces would never start working together. Slow, inefficient system test efforts due to the test group getting hardware and software that weren't really finished. Never-ending test phases where each fix seemed to produce new bugs. Products shipping to a customer, only to crash on the first day of operation, because the test plan wasn't thorough and real world. Your development team members are obviously not the project manager, functional manager, or test manager - the people typically seen to have overall responsibility for planning and managing these efforts. But those developers still have a great deal to contribute to help make sure these nightmares don't occur. The developers are closest to the design details. They've had to implement those requirements. If your developer team members are acting as vanquishers, they'll speak up during planning about what types of testing should occur and how they should be organized. They'll make sure they do thorough design reviews to eradicate bugs early, where they cost less and are far less painful to deal with. They'll help make sure that they and others tightly control late changes and bug fixes, make only the necessary ones, and review the changes appropriately. In short, those team members' oversight of these issues is at least as valuable as that of all the "managers" involved.

So think about your project's design, implementation, and test challenges. Where can you and your technical team members take more ownership, take more initiative, and act as valuable "vanquishers"? If you're a project manager working to influence more of this behavior on your team, here's the big side benefit that can help: The fact is, Vanquishers are valued. They get listened to, appreciated for their maturity, promoted, and given the best opportunities on the next project. It can and should be you and the other members of your team.







©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 info@projectconnections.com
Terms of Service and Privacy Policy