The gift that keeps on giving

Every now and then, an odd thing happens: a manager takes on a tough business problem.  (not so odd).  But the problem comes with a team that is supposed to be hand-picked to solve it.  Literally, the project shows up, resourced and all, and gets handed to a manager like a gift. 

That should be your first hint. 

Then the project starts, and sure enough, stuff starts to slide.  The team is doing what they say they will do, but the customers keep making noise about 'concerns' and 'requirements'.  Before long, all the estimates and planning assumptions go right out the window. 

What's wrong?  I can spin up a lot of reasons, but the one I've run into the most is this: the team doesn't understand the business problem.  They may have a really good idea of the technical problem.  They may even have great people with great ideas that are passionate about delivery.  But if they don't align to the business problem, then they are toast.

An astute PM may notice this.  They may be able to correct course and get things back on track.

If the PM is not astute, or is too novice to question, or too stubborn to admit defeat, or is a contractor/hired hand, they may just let the train keep rolling and hope that their bravery and iron will can save the day.  (It can't.  It never can).  Net result: the team continues to try to solve the wrong problem.

This is the hidden risk in all projects: that the team doesn't really understand the requirements.  I don't mean the DEV team... I mean the ENTIRE team, including the analysts, program managers, engineers, testers, and so on.  In short: everyone. 

Here's an example.  Note: this is not indicative of any current MS IT project.  This is from past experience in my consulting days.  However, I've seen this behavior before and expect to see it again.

Let's start with our team.  Just for fun, let's call them Epsilon.

Team Epsilon is chartered to create a tool that many internal customers need to share.  (Marketing is a frequent victim of these kinds of things, unfortunately).   Let's say that Customer X gives 30 requirements and that Customer Y gives 40.  They only overlap a bit.  So Team Epsilon creates a plan, and they agreed to roll out only the overlapping part in phase one.

Bad move.  Now, the overlapping part is not enough to satisfy either customer.  So Team Epsilon publishes their plan, and both customers balk.  Neither one wants to pay for phase one.

There are many different outcomes to this story. 

1. The PM changes course, and they decide to build for Customer X first, and then add on Customer Y second. 
2. A new approach gets Customer X and Y to agree on a subset that would actually be useful to one or both. 
3. The entire project gets outsourced (which is another way of saying, "fire the team and start over.")
4. Here's the one I started with: What if the entire team is moved to a new manager? That will solve the problem... right?

The new manager takes on the team, flaws and all, and agrees to solve the problem.  He doesn't really know what the problem is, so he talks to the team.  They give him their view, but it is precisely that view of the problem that prevents its solution.

Of course, this little bit of deck-chair-shuffling doesn't solve the business problem either.   The manager who got rid of the team solved HIS problem... he's not getting noise from Customer X and Customer Y anymore.  The customers are still in the same situation. 

So if you are a manager, and someone hands you a problem along with the team to solve it, it is OK to accept the problem, but if you do, take my advice: Dissolve the team into your organization.  Form a new team, with a proven track record.  Then, start over. 

Most importantly, question everything.  Get customers in the room, without the old team present (or with the new team, sitting quietly).  Listen.  Ask follow-up questions.  Find out what is going on. 

Sometimes, the tree needs to be shaken before the fruit can fall.