Fighting the Long Tail
In the last couple weeks after coming back from Boston, I’ve been sliding into more of a project management role. Not the first time I’ve found myself in this position, these assignments have been huge learning experiences in how to properly organize a team around a central goal.
On my current project, we discovered that the Outlook Client we released for CRM 3.0 has some incompatibilities with Vista and Office 2007. Several issues are showstoppers and our customer commitment mandates that we needed to dedicate resources to updating the design of our client. (Not to mention a desire/need to ride the biggest release wave in Microsoft history.)
Splitting up a large team between two projects is always a risky and painful proposition. In this case, we have a big mainline project to build CRM 4.0 (Titan) and a significantly smaller project to build an updated CRM 3.0 Client. From a project management standpoint, this complicates things considerably because you now have competing focuses and goals on the team. By virtue, small, out-of-band projects standing in the shadow of a larger one don’t get the same level of attention and run the risk of derailing.
Two ways to mitigate the risk of derailment is buy-in from management and strong project leadership. I’ve got lots of the former and it’s up to me to deliver on the latter.
What I’ve learned from previous out-of-band projects is the danger of the long tail. This is the project that never ends because of minor issues that continually trickle in. It is important to note that no piece of software is ever bug free and that the goal is to ship the best thing reasonably possible. The long tail, which holds back projects and their members, spawns from an inability to define crisp criteria around what and when something is ready to be shipped. I’ve been bitten by this in the past on The Project That Refuses To Die.
I spent last weekend figuring out a strategy to ensure that the long tail doesn’t haunt me again. Taking a cue from my compatriots over on the Office team, I’ve adopted a simple timeline. It starts from today and goes until a target shipping date. In between, I bracket off periods of time and declare what the bug bar will be for that span. The bar starts at Severity 2+ and eventually ends up at “Ship Mode, Sev 1 Bugs Only.”
After working out the timeline, I went to my team and got them to commit to the schedule and to the release date. After all, I wanted to be sure that the schedule I set out was realistic for my team to act on and drive towards release. At this point, I’ve gotten everyone to agree on the schedule.
We’ll see if I’m pulling my hair out in five weeks.
Reposted from Adventures of a Vagabond
On my current project, we discovered that the Outlook Client we released for CRM 3.0 has some incompatibilities with Vista and Office 2007. Several issues are showstoppers and our customer commitment mandates that we needed to dedicate resources to updating the design of our client. (Not to mention a desire/need to ride the biggest release wave in Microsoft history.)
Splitting up a large team between two projects is always a risky and painful proposition. In this case, we have a big mainline project to build CRM 4.0 (Titan) and a significantly smaller project to build an updated CRM 3.0 Client. From a project management standpoint, this complicates things considerably because you now have competing focuses and goals on the team. By virtue, small, out-of-band projects standing in the shadow of a larger one don’t get the same level of attention and run the risk of derailing.
Two ways to mitigate the risk of derailment is buy-in from management and strong project leadership. I’ve got lots of the former and it’s up to me to deliver on the latter.
What I’ve learned from previous out-of-band projects is the danger of the long tail. This is the project that never ends because of minor issues that continually trickle in. It is important to note that no piece of software is ever bug free and that the goal is to ship the best thing reasonably possible. The long tail, which holds back projects and their members, spawns from an inability to define crisp criteria around what and when something is ready to be shipped. I’ve been bitten by this in the past on The Project That Refuses To Die.
I spent last weekend figuring out a strategy to ensure that the long tail doesn’t haunt me again. Taking a cue from my compatriots over on the Office team, I’ve adopted a simple timeline. It starts from today and goes until a target shipping date. In between, I bracket off periods of time and declare what the bug bar will be for that span. The bar starts at Severity 2+ and eventually ends up at “Ship Mode, Sev 1 Bugs Only.”
After working out the timeline, I went to my team and got them to commit to the schedule and to the release date. After all, I wanted to be sure that the schedule I set out was realistic for my team to act on and drive towards release. At this point, I’ve gotten everyone to agree on the schedule.
We’ll see if I’m pulling my hair out in five weeks.
Reposted from Adventures of a Vagabond