I believe the concept of teamwork often gets turned into some fluffy, warm and fuzzy “thing” that no one quite knows what to do with … an ephemeral idea of a bunch of people working together in unadulterated harmony or even outright bliss. Great if you can get it but not something I’ve seen a huge amount of and certainly don’t count on.
Instead, I think teamwork is really a combination of individual acts of initiative — to pay attention to and act on details of the project personally — for the greater good of the project. But that requires individuals to understand HOW they can contribute to the good of the project from beginning to end, and sometimes outside the realm of what they thought was “their job.”
To judge where your team is on this kind of individual initiative, consider these questions about what roles your team members take at the beginning of a project:
- Are they involved near the very beginning and are glad to be?
- Are they involved near the very beginning and are sorry because it’s extra work, ambiguous, etc.?
- Are they not involved and don’t want to be?
- Are they not involved and do want to be?
If your answer was 1, great! Simply read on to make sure your team members are really maximizing their influence during the critical start-up phase of the project.
If your answer was 4, they probably understand that if they were involved early, they’d have important things to say and ideas to contribute!
If your answer was 2 or 3, they probably don’t know what they’re missing in terms of influence and satisfaction! In the rest of this post I cover some ideas on why they need to be valuable contributors to a project’s start — and hopefully you can use these ideas to help them see the possibilities.
Why are Project Starts Critical?
- It’s where the product features and project goals get set. (What are we developing, and why?)
- It’s where the high level design gets created. (What will you be developing?)
- It’s where the schedule gets determined. (Will it be reasonable? Impossible? Be absent at your peril!)
These three aspects of the project start phase point to important reasons and ways for every team member to be involved.
Product Features and Goals: New team members may think Marketing has all the answers about what should get developed on this project. But of course, they don’t really. Customers have many needs and wants; and companies have many project options, limited resources (us!) for executing them, and really tough decisions to make. Do we release in 12 months with the whole feature set we’d like to have, or release in 4 with a subset then follow on with more? Do we spend our time on cost reduction or move right on to the next platform development?
Many of these decisions come down to cost-benefit tradeoffs that depend upon the realities of the engineering work — team members’ work. How much software or hardware work is really involved in the different product capabilities? Where is the big technical risk hiding? Only your team members know for sure. So smart companies involve engineers way at the beginning of the project, to help sort through the “do-ability” of product requirements. Do your team members know how to be involved like that? Are you letting them be?
High level designs: How can you answer the above questions about technical work and risk? By getting started on the high-level design work while requirements and schedule are being discussed. When Marketing lays out the project requirements, the only way to determine whether they can be implemented within the desired schedule timeframe is to do engineering high level design. Is that new platform going to require 5 different hardware modules and 50 software modules? Is that new, supposedly easy software-only feature really going to require updates to 5 major software subsystems and a hardware revision? Again, only your team members know for sure!
Schedules: What you learn from high-level design work will definitely affect the project schedule. That whiz-bang feature upgrade list sounds fabulous until someone does some design work and tells Marketing that the implementation schedule is 8 months instead of 5. Market needs drive many schedules these days; feature or cost tradeoffs may well get made to hold a particular release date or window. Team members’ technical knowledge of the work at hand is absolutely required, very early on, to help make sure the right decisions get made for the company. Same thing with deploying and supporting a project, or doing testing, or preparing user documentation.
The times I’ve had plans and schedules with no huge gotchas are the times I had team members doing design work, planning for customer deployment, investigating manufacturing test approaches, looking for regulatory issues WAY EARLY, and contributing their knowledge before the plans were even beyond the squishy stage. The product definitions and plans were not allowed to get anywhere close to hard until all the inputs were in. The team members got to think through these aspects — they saw that they weren’t all for “later.”
Sound obvious? Perhaps, but this is NOT the way we necessarily run our teams. Perhaps those cross functional people aren’t available early because they’re off deploying the last product. Or perhaps they just want specs thrown at them and really don’t like the ambiguity of the front end. Or perhaps your company has a culture where planning is compartmentalized from the detailed technical doing and people are resigned from the past to not getting a say. Whatever it is, it’s up to the project manager to create the right atmosphere and process to bring your people together in this kind of team, where each individual brings their knowledge and initiative to bear from the beginning. It’s what THEY know about the realities of what you’re trying to accomplish that absolutely must be brought to bear on the early definition, investigation and planning activities.
The bottom line is this: every team member is incredibly important to the decisions that get made early on in a project. Their knowledge of what it will really take to get the whole job done are critical. If they’re not getting a voice now, help them get it and make sure to thank them and welcome their inputs. And make sure they understand that this is real team work — each understanding their critical contributions and working hard to make their own, and to help their colleagues each make theirs too.
