Everyone agreed the organization needed change. The IT department had lost another leader from the top job. After going through four leaders in about as many years, the question was, what kind of leader would be coming in next?
The original IT leader did not have many processes and didn’t believe in project management. If you were connected or had friends in the department you could get something done. Conversely, if you didn’t have the connections, you didn’t have much chance of being heard. Let’s call this leader “Cowboy.”
Cowboy’s replacement brought in great people and best practices. It was easier to be heard if you could figure out how to get your idea through the process. The work was more organized with Project Managers and Analysts and loads of paperwork. And meetings, there were many, many meetings. This leader lasted for a few years and we will call him “Process Heavy.”
The next IT leader said the process was too heavy and we needed a new, lightweight method. Scrum was introduced to developers and the staff was reorganized from departments into teams. The new method was held onto so tightly any variance or deviation was shunned and cast aside. The teams were happier and the business liked getting small bits of work more quickly. Unfortunately, the new process brought a confusing new vocabulary and large projects never finished. This leader is the “Developer’s Friend” and he lasted for much less time than his predecessor.
The fourth IT leader felt like a breath of fresh air. “We should be a bit more flexible with our process,” he said. And the business liked when he told them “Yes.” He told all of them yes without a way to give them what they wanted. So the staff with less process had more work. And the business eventually tired of hearing everything is okay when they could not get results out of IT. This leader will be “Yes Man.” He didn’t last very long at all.
No one in the department was willing to guess what the next leader would be like. They were willing to open a betting pool on how long he would last though.
All of the IT leaders above wanted to do a good job and help the business achieve meaningful success. They all want to enable their staff to meet the business needs. “Cowboy” thought he was being responsive to the business by avoiding overhead. “Process Heavy” added vital tools for both project selection and increasing the chance of project success. “Developer’s Friend” gave programmers a better framework for building things right and increasing project success in an entirely different dimension. “Yes Man,” like his forerunner “Cowboy,” was trying to be responsive to business desires. Despite their similar intentions, these leaders offered inadequate solutions for the challenges they faced. None of them added the value their customer needed.
The traditional view of software delivery projects is a fundamental part of the problem. This paper explains the shortcoming of how IT departments look at work and concludes with an integrated solution for increasing value and business satisfaction.
Why is IT struggling?
The forces pushing IT departments to change are multi-faceted yet we have continued to address most everything with the Iron Triangle of Scope, Schedule, and Cost. This response has been a largely inviolate part of not just projects, but IT’s approach to every challenge.
Forces of change threaten to overwhelm us
Pressures to triumph in the marketplace are greater, the rate of change is accelerating, and the opportunity for your competitors to leapfrog past you with new technologies – from social media to big data – grows daily. If you consider the example of software products, AOL reached 1 million user in 9 years. Facebook reached the same milestone in 9 months. And recently introduced Draw Something reached this threshold in about 9 days!
Within organizations projects are failing, investments are over budget[i], waste feels rampant, and very few people understand the expected or resulting ROI. Chief Executive Officers list technology as their #1 concern worldwide.[ii] Meanwhile, prevailing processes continue to inhibit change within the organization. The Economist reports, “The main obstacles to improved business responsiveness are slow decision-making, conflicting departmental goals and priorities, risk-averse cultures, and silo-based information.”[iii]
Combine these factors with a talented workforce desiring to be appreciated and heard[iv] and the roar for change can be deafening. The Iron Triangle works well in some circumstances, but rapidly deteriorates as the rate of change increases.
We confuse Strategic and Utility IT
IT stands alone in with its regular need for large capital projects too often characterized with poorly conceived goals and ill-defined benefits. In part, this stems from confusion between strategic and utility IT services. IT departments provide both service types without understanding the differences. Ross Pettit explains, “This is not a separation of IT by the nature of the technology, but into what technology does for the host business.”[v]
Consider a replacement Inventory Management system for maintaining a retailer’s inventory levels, orders, sales, and deliveries. This software may be cloud-based or internally hosted, integrated with RFID tags or not, developed in-house or purchased from a vendor, etc. Either way, it provides a basic service for organizing inventory data and controlling stock levels. Not having an inventory management system will hurt your business, but having this system does not add strategic value. Replacing an old inventory management system with a new one is unlikely to give you a substantial increase in market share. Worse, if you do not have goals for how this will impact your vendor interactions, inventory turns, or bottom line and then quantity the project success against those goals, there will be significant doubts if the project even added value. The inventory management system is a utility service.
On the other hand, some IT services qualify as strategic. Projects allowing your business to catapult over competitors are strategic. Investment banks are willing to invest multiple millions of dollars to enact trades faster. The transaction speed in this circumstance is strategic. Especially for the first bank able to trade faster than its peers.
An important point to remember in settings of competition and change, is today’s strategic service is tomorrow’s utility. When all of the trading firm’s competitors can trade at the same speed, then the strategic value is replaced with utility value. It is still required, but it no longer provides a strategic impact to the firm. More, if the utility is not maintained, the firm may need to spend strategic-level amounts of money to catch up to peers. The size of this expenditure, however necessary, is a cost of doing business rather than strategic investment.
Another reason IT departments are less effective is because business executives do not adequately understand this difference. The dividing line between these types of services and projects may be grey and the rationale for better utilities may be filled with grand prose and grander numbers, but treating these projects in the same way is inefficient. Martin Fowler alludes to using the Iron Triangle incorrectly when he writes, “The way you staff, run, and budget a strategic project is entirely different to how you do a utility project. Too often people assume that what is good for one is good for the other – and trouble inevitably follows [emphasis added].”[vi]
We measure and reward project success incorrectly
Traditional project delivery has centered on defining the project and producing to the entire scope. This approach generally introduces waste and unnecessary costs into projects, pushing for understanding based upon needs for today’s environment and focusing on complete solutions. It is unreasonable to expect competitors and government regulations to stand still while projects are analyzed and developed. Today’s businesses move too fast for this.
Tom DeMarco, who famously wrote, “You can’t control what you can’t measure,” recently explained this oft quoted line has the wrong implications, that control may be the most important aspect of a software project. He now states “…the more you focus on control, the more likely … (your) project … (will) deliver something of relatively minor value.” Following this, he states:
“For the past 40 years, we’ve tortured ourselves over our inability to finish a software project on time and on budget. This never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.”[vii]
Successful projects are often met with recognition and bonuses, especially for project managers and executives. “Success” being defined as producing the initial project scope on time and in budget. We are rewarding the same behavior we are measuring, control. This reward system drives teams to finish projects for the wrong reasons, because they want the monetary reward and recognition, rather than adding the value we need today.
The implication in DeMarco’s statement is the last four decades have favored those goals and projects that are easier to control. When the IT department aims for projects that can succeed within the boundaries of the Iron Triangle they do not reach great success. These projects may be good for the both business and benefit individuals, but they rarely transform the business or customers.
How can IT be more effective?
We need a different solution for this challenge. The correct response encompasses a number of changes to how we view projects. Teams need a new toolset to handle the work before them. Going forward, we must recognize more than achieving negligible scope statements, choose projects for learning and impact, and build for long-term success. This needs to be accompanied by incentive models that recognize control is not our best gauge for achievement.
We need to pick the right model
Jim Highsmith has already given us a new model for viewing projects. In Agile Project Management, he suggests depreciating the traditional Iron Triangle.[viii] The real goals of projects is “producing value that delights customers, building in quality that speeds the development process and creates a viable platform for future enhancements, and delivering within constraints.”[ix] Viewing the Agile Triangle, it is obvious the traditional view is still important, but as a set of controls rather than the primary focus.
The Agile Triangle
The Agile Triangle concentrates attention on releasing products adding value to users and developing sufficient quality for today and tomorrow. Shifting priority from constraints to value and quality gives more weight to what is being delivered than how it is delivered. This change does not mean the how’s of delivery are unimportant. Rather, the how’s need to take a back seat to why we are developing software. The reason for software development is not software itself. The reason for software development is to provide some other benefit via the software!
Deliberately shifting from producing the entire project scope to making small, meaningful differences results in systems with less complexity that are easier to maintain, update, and fix. With smaller, higher quality code bases, there should be a corresponding maintenance cost reduction for the life of the system.
Existing compensations and reward systems will need reevaluation because they create pressure to maintain the status quo.[x] New reward systems will prize the ability to critically assess a project based on factors of learning, delighting customers, and adding bottom line impact.
Customers will find their needs satisfied much sooner with these changes than the traditional project end date.[xi] Highsmith reports clients delighted with only 20 – 30% of the originally anticipated functionality.Moving from the Iron Triangle to the Agile Triangle allows us to change the notion of value from, “Have we completed the project scope within schedule and budget?” to a more useful question, “Have we obtained enough value to redirect our investments to something else?”
We need governance focused on delivering value
IT Portfolio Management ensures resources are properly allocated across projects and business needs. This conversation starts before a project gets to IT with understanding of the corporation’s strategic goals. With this knowledge, the aim of governance becomes ensuring IT is aligned and adding the appropriate value.
Aligned with the Agile Triangle, governing with transparency allows IT and business leaders to act on the delivering the highest value while considering changing business needs. This transparency includes the business’ estimate about value received to date versus the cost, and expectations about future value and cost. This system will put vague and unsupported claims under greater scrutiny and simultaneously recognize halting marginal projects is not a failure, but a savings.
“Process Heavy,” the second IT leader did the organization a favor by adding IT Portfolio Management. With this addition, the business had a framework for talking about what projects were needed and why. He brought in metrics measuring success and built a strong team. Unable to make changes fast enough, he did not add all the tools required for larger, lasting success. Adding governance without the corresponding ability to nimbly adjust to changing conditions is a partial solution.
Similarly, “Developer’s Friend” changed the environment for development teams and gave the IT department new tools, allowing for a nimble response and improving employee morale. Done well, these changes move software development from a hit-or-miss exercise to one where developer productivity is constant and the output is “built right.” Unfortunately, he lost support when the process became more important than the project and goals. Adding delivery without maintaining governance is inadequate.
The solution is adding proper governance to an environment skilled in quickly creating working software. While the focus needs to be on producing value, the environment must accommodate change in response to the business environment. The best use of IT Portfolio Management includes realizing value while projects are ongoing, before reaching the end of their planned timeline.
IT departments, leaders, and projects struggle because of a historical reliance on the Iron Triangle. It is not the right tool for dealing with rapidly changing and extremely competitive corporate environments. The implications have left departments focused on control when we needed experimentation and learning to achieve business-changing goals. Repeating what we have done before, we measure and then reward the wrong behaviors.
Effectiveness does not have to ephemeral. Using the Agile Triangle and good portfolio governance, this paper presents a solution centered on a fundamentally different outlook for IT activities. These interlocking concepts combines value with quality, control with reward systems, governance mechanisms with transparency, and skilled employees that incrementally deliver value. The astute IT leader is beginning to embrace this view.
While divergent from traditional thinking, this proposal builds upon experience gained over the last two decades. These ideas are already being tested on a piecemeal basis within organizations. Each idea succeeds on the strength of another. No one idea, standing alone will meet business needs. Combined, this approach elevates projects out of bad control loops and into meaningful contributions. There is a revolution around the corner for IT projects, impacting business leaders and strategy alike. The next strategic advantage from IT may not be software, but how it views projects and contributes to the business.
Sources:[i]Standish Group. “CHAOS Reports.” http://blog.standishgroup.com/.
[ii] IBM Corporation. “Leading Through Connections: Global Chief Executive Officer Study.” May 2012. http://ibm.com/ceostudy.
[iii] The Economist Intelligence Unit, The Economist. “Organizational agility: How business can survive and thrive in turbulent times.” 2009. http://www.slideshare.net/EMCsoftware/the-economist-organisational-agility.
[iv] Mike Myatt. “10 Reasons Your Top Talent Will Leave You.” Forbes, Dec. 13, 2012, accessed June 26, 2013, http://www.forbes.com/sites/mikemyatt/2012/12/13/10-reasons-your-top-talent-will-leave-you/.
[v] Ross Pettit. “Separating Utility from Value Add.” July 09, 2010 blog post. http://www.rosspettit.com/2010/07/separating-utility-from-value-add.html
[vi] Martin Fowler. “UtilityVsStrategicDichotomy.“ July 29, 2010 blog post. http://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
[vii] Tom DeMarco. “Software Engineering: An Idea Whose Time Has Come and Gone?,” IEEE Software Magazine, July/August, 2009.
[viii] Jim Highsmith. Agile Project Management: Creating Innovative Products, 2nd edition. Addison-Wesley Professional, 2013.
[ix]Highsmith. “Beyond Scope, Schedule, and Cost: The Agile Triangle.” November 14, 2010 blog post. http://jimhighsmith.com/beyond-scope-schedule-and-cost-the-agile-triangle/
[x] Felipe Furtado, Gibeon Aquino, and Silvio Meira. “Improving Organizational Performance Through Reward Systems,” in Business Dynamics in the 21st Century, Dr. Chee-Heong Quah (Ed.), InTech, May 2012.
[xi] Standish Group, ibid. Studies have shown up to 60% of software functionality is rarely or never used!