Calling the shot

Time to start blogging again....and how about a sports analogy? On October 1st, 1932, at Wrigley Field in Chicago Babe Ruth hit what would be his last World Series home run as the New York Yankees beat the Chicago Cubs 7-5, on their way to a four game sweep of the series. What made the hit remarkable was that Ruth allegedly pointed to the center field bleachers before dispatching the ball there. A famous sportswriter immediately wrote that Ruth had actually pointed to where the ball would land before taking his fateful swing...and a sports legend was born.

The fact that Babe Ruth was probably pointing at the Cubs dugout in response to being jeered has been lost in time, because our nature wants us to believe in the hero rising above normal performance to perform incredible acts.

Project management for software development sometimes feels this way - when as the leader of a project you are expected to say exactly how things will turn out. Since we're not all Babe Ruth about to hit a last legendary World Series home run, we have to rely on other methods.

More often than not we are required to specify some end result and a time line before the project starts. We are asked, in a sense, to 'call the shot' before the team even picks up a bat. So, having called the shot, what fundamental things are involved in trying to make it happen? Thought I'd share some thoughts, if not gross simplifications (apologies to my PMI friends in advance), regarding where you should focus to help make your 'called shot' become reality:

• Resources: Team members (skills, experience, availability, attitude), facilities (desks, computers, networks, etc), and tools (source code, automated builds, code coverage, etc). Avoid deficiencies in any of these areas.
  
• Requirements: Stories, broken down into tasks, solid estimating (relative for stories, detailed for iteration tasks), lightweight task & progress tracking, user buy-in to author the stories and their accompanying tests (i.e. how do we know if feature x is complete?)
  
• Design: Do we have a clear technical design? Interaction design? Does it match the skills & capabilities of the team? Is it balanced to handle complex and simple functionality? Are the abstractions reasonably waterproof? Is it pragmatic and as simple as possible?
  
• Organizational support: Are we communicating clearly and frequently enough to all stakeholders? Are risks well understood and mitigated? Are we clear on our expectations of all stakeholders? Do the right people care about our project?
  

If you pay enough attention to these four basic areas, with no 'fuzziness' in them then you'll have a much better chance of actually calling your shot. Whereas some still question the Babe's heroics, you'll at least have the satisfaction of having your called shot well chronicled.