In a conversation on Twitter with Sridhar, there was mention that product development software projects are different than internal IT projects. And that how they are run is much different as well. This may be the case. It's not been the case in my experience in Enterprise IT for those internal projects. My experience in product development (FileNet, Triconex, Kontron) and software intensive program delivery for government, defense, space, and energy clients is that projects are expected to show up on or before the planned date, at or below the planned cost and with the agreed set of minimal capabilities to accomplish the business goals or fulfill the needed mission.
When internal IT projects lose their ability to show up on time, on budget, with the needed capabilities - all within the probabilistically defined bounds of those measures - then they lose their seat at the table. Internal IT becomes a cost. Sometimes a sunk cost. An expense. A necessary expense, but an expense all the same. And when you're only an expense, those making decisions tend to treat you differently. You have no tangible way to show your worth. In business worth is defined by revenue or cost savings. In both cases worth is defined in units of money. When you have only cash outflow you're likely not to be in the conversation about how to run the business.
There are endless books, articles, and academic papers on the topic of getting a seat at the table. Successfully delivering internal IT in support of the business. Keeping your seat the table on that business requires very specific behaviours, starting with three simple questions:
- How much will this cost?
- When will you be done?
- Will it work at needed when you're done?
But the bigger question - the killer question is what are we building and why are we building it? Ignoring for the moment the problem of showing up late and over budget dilutes any value produced by the project, some times to ZERO, we must have a notion of what DONE looks like in units of measure meaningful to the decision makers. Those paying the bills for the project.
Below is a briefing of how to answer these governance questions about what and why. With that in hand the how much, when, and working are straight forward.
- IT Governance: How Top Performers Manage IT Decisiion Right for Superior Results, Peter Weill and Jeanne W. Ross, HBS Press, 2004
- Reinventing Project Management: The Diamond Approach to Sucessful Growth and Innovation, Aaron J. Shenhar and Dov Dvir, HBS Press, 2007
There are many books on Balanced Scorecard. Some I find best are:
- Strategic Performance Management: Leveraging and measuring your intangible value drivers, Bernard Marr, Elesiver, 2006.
- Balanced Scorecard Diagnostics: Maintaing Maximum Performance, Paul R. Niven, John Wiley and Sons, 2005.
- Strategy Maps: Converting Intangible Assets into Tangible Outcomes, Robert S. Kaplan and David P Norton, HBS Press, 2004.
At The End of the Day
If you can't say, with some degree of confidence, how much you plan to spend, over what period of time, to deliver some tangible value to those paying for your work, you're not in the room when those paying for the work ae deciding what they want you to do. You're considered an expense - possibly a valuable expense.
