Are You Holding Back Your Team’s Success?
Recently, I hooked up with a friend and decided to do a 3-day hike on the Appalachian Trail. As part of our preparation, we decided to try a day-hike in a State Park near our homes. We took this trial quite seriously and even planned how to mentally and physically prepare for the day hike. I won’t bore you with the details, but the day we set out for the hike, we were pretty psyched.
We did 8+ hours on the trail, walking up and down paths that burned our legs by the end of the day. In the last hour or so, when were truly coming to our “wall of tolerance”, we kept repeating to each other how fortunate we were for all the planning. Had we not trained for this or lacked the right supplies, we would have never lasted the day. Without a doubt, doing the day hike before setting out on our 3-day hike out east was the smart thing to do.
We focused on setting ourselves up for success. And even with all the planning, we still learned a lot about what to do differently on our next day hike.
Learning From the Hike…
I can only imagine how painful that day would have been if we didn’t work our way up to walking an entire day of 13+ miles. Or what would have happened if we only had half our water ration (we used it all). It would have been one embarrassing, failure of a hike.
This is a far more common scenario than any of us realize. When we start a new project, we typically overlook fundamental / key things that would set us up for success. We may actually be holding our team back from the start. And because of that, our team may be digging out from this “team debt” for the majority, if not all, of the project.
Hold Up There
If you don’t agree, let me give you just two common scenarios that prove my point:
- You are starting a project. The team is staffed and eager to move forward. The technical team is building out the environment and frameworks. The Business Analysts are ready to collect and refine requirements, but are struggling to get the needed time and commitment from the business.
This not only causes churn for the BAs, but typically squeezes the schedule during the initial coding activities, with incomplete requirements and test plans.
- Another example: You are staffing up a project quickly so you can hit a set of aggressive dates for the business. In doing so, you need to procure development environments and machines for all of the developers. However, due to an overworked infrastructure team, or worse, due to corporate processes, a third of the team may be without development hardware and tools while they wait for their stuff.
While they find other activities to do while they wait, this literally amounts to two or three weeks that could have been spent on actual deliverables.
These are just two common examples. You could probably start listing off a couple more.
What Are They Thinking?
So when this happens, what is management thinking? Are they intentionally setting a team up with an obstacle? Do they simply not care and assume we can adapt?
I believe that in most cases, management simply doesn’t realize that the team is being put into this position and the cost is more than a slow ramp-up to the project. I, myself, have asked teams to “see if they could work around some obstacles”, clearly not realizing the pain I may be introducing, not just short term, but to the long term success of the team.
So What Are We To Do?
I think one of the most basic things we can do in these situations, is to be vocal. Share your clear and honest explanation of what the cost and impact is. It is important to be accurate and not embellish or magnify the challenges.
For example, let’s say you have a project starting and are scheduled to collect requirements for the first deliverables during the week of 11/01. Your goal is to have the requirements and test plans completed by 11/15 so the developers can begin development.
If the business stakeholders are not available as needed the week of 11/01, I think it’s important to point out that development may not start until 11/22. This is because the test plans won’t be complete and the requirements won’t be clear enough (the normal clarification won’t have happened).
If you can clearly show the cause and effect, management should take ownership of the cost and impact of these situations. If we can show them the cost in terms of dollars or in terms of schedule, then you have the best shot of setting your team up for success and getting management to own the challenges.
What do you think? Have you found other approaches to help set teams up for success?
Category: Business-IT Alignment, Team Dynamics, Team Performance