Goal, Goal, Who's Got the Goal?

How Unaligned Goals Impact Your Bottom Line
"Never attribute to malice or stupidity that which can be explained by moderately rational individuals following incentives in a complex system of interactions." Hubbard’s Corollary to Hanlon’s Razor

I recently visited a team I worked with to see how they were doing. In an effort to get control of feature creep, the IT department directors instituted an "analysis/design" phase just after I left the project. This phase resulted in the creation of a design packet containing all the information the team would need to develop the software. If the team had questions, they could ask the systems analysts for clarification. This decision did remove change requests from the client (another business unit in the company). It also disconnected the team from getting more information about the client's goals.

When the client representatives began user acceptance tests, they refused to accept the software until changes were made. The team worked on the changes and delivered the software six weeks late. While six weeks doesn’t seem terrible, let’s take a look at the costs associated with the schedule slip.

Failure Demand
Software teams' productivity falls in two basic categories: value demand and failure demand. When the team started the project, they spent their time on value demand and created value for the client. As the project got closer to completion, the team delivered completed functionality to the external QAT testers. When the testers sent defects to the team, the team shifted to a combination of value demand (creating new features) and failure demand (correcting defects). In the final six weeks, beyond the original twelve-week schedule, the team spent 100 percent of their time doing failure demand work. I don’t know what the loaded cost for the seven team members was, but it was a cost that could have been avoided if the IT directors had the same goal as the client.

Lost Opportunity
For the six additional weeks the team worked on this project, they could not add the next project to the queue. This meant that the potential revenue and benefits for the next project could not be realized as anticipated. Making matters slightly worse, the six-week shuffle affected delivery of the next project because major deployments to production occurred quarterly and delivery for the new project didn't happen until the next drop window.

Confidence
We can assign a reasonably accurate number to the six weeks of failure demand. Using the calculations that justified the next project, we can anticipate how much the lost opportunity cost. We can't assign a value to the loss in confidence the client organization now has in the ability of the IT department to deliver on its commitments.

From the Top Down
Here’s what to do to make sure your project, sprint, and daily goals align:

Project Goals—Charter And Vision
Check your project charter. In what way does the charter support a major strategic goal for your company? If you can’t find a charter for your project, create one and share with your boss and your boss's boss. Tying your project to a strategic corporate goal, such as "Increasing Market Share" or "Expanding Current Product Lines" provides the long-term goal teams need for framing their activities.

With a project charter that supports a strategic goal, you can then examine the product’s vision statement. The product vision also provides a touchstone for the team to use as they work. If you don't have a product vision, you might consider using Jim Highsmith’s information on product vision to create one. If you create a product vision, be sure to include those who will use the product. The problem I experience most often with charters and visions isn’t that they don’t exist; it’s that they rarely make it to the team level.