As companies adopt more cloud IT services and work with an increasing number of service providers, the tried-and-true IT towers of the \n\npast no longer serve their needs. "The old model lacks the clarity of ownership required to drive decisions on as-a-service offerings that span \n\nthe traditional tower structure," says Steve Keegan, principal with outsourcing consultancy Pace Harmon. "Determining who makes the call isn't straightforward -- the server team, the app team or the database \n\nteam?"\n\nIT groups need to reorganize around processes rather than technology areas, such as infrastructure or applications. In process-driven IT \n\norganizations, "people are focused on activities that are of long-term benefit to the organization with clear accountabilities and increased \n\nefficiencies in how work gets done," Keegan says.\n\nBut such "plan-build-run" models often don't take -- for a number of reasons. "Application teams still dominate the decision-making process. \n\nLegacy applications leaders don't want to diminish their authority to drive investment decisions," Keegan says. "Leadership doesn't hold their \n\nown managers accountable for minding boundaries. The architecture function lacks the resources they need to be successful and therefore \n\nbecome strictly oversight with no real time to contribute and provide planning insight to project and program leaders."\n\nThose IT groups that do successfully shift to plan-build-run have clear leadership support and make the change wholesale, instead of letting \n\ncertain groups continue operating in the manner that they always have.\n\nKeegan offers five tips on transforming IT into a process-driven organization:\n\n1. Enlist an army of business analysts.\n\nThese IT professionals should align themselves with business relations -- not the applications -- to handle upfront planning. They will have \n\nthe business process knowledge necessary to clarify changes that will be required in the applications landscape and create new and consistent \n\nbusiness processes. "There are often far fewer business analysts than anyone believes is sufficient," says Keegan. "Business analysts provide a \n\ncore competency in aligning business needs for change with the underlying systems that support that business."\n\n2. Don't skimp on planning.\n\n"The early project phases of scoping and planning that ultimately feed the business case are indeed worthy of sufficient investment, and \n\nare not only valuable in assuring that investments are targeted correctly, but are legitimately allocable to project investments since their \n\npurpose is scoping, defining a plan for, and justifying the expenditure of investment to achieve strategic business objectives," Keegan says.\nPlan to spend about 5 to 10 percent of project time (and cost) developing a business case. "Spending more time planning creates not only \n\nmore certainty that you'll be pleased with the outcome, but you will know when you break ground that you won't be making too many changes \n\nto the plan once you start," says Keegan.\n\n3. Put architecture in charge of application planning.\n\n"It's fine to leave application teams in charge of portfolio and roadmap planning -- so long as you don't ever want to retire an application or \n\nsimplify the support and resultant cost of the application landscape," Keegan explains. "Traditional application leaders typically attempt to \n\nexpand their control by increasing complexity, expanding the application suite resulting in increased licensing and maintenance cost, and \n\nexpanding complexity of the resultant support \u2013 because they are accountable for delivering individual projects, not the cost of supporting what \n\nthey put in. \n\nArchitects have a mission to optimize the portfolio, reduce total cost of ownership, and leverage investment to the greatest degree \n\npossible." Incentivize efficient utilization and rationalization of the application suite, retirement and migration of less used or expensive to \n\nmaintain applications and platforms, and optimal cost and quality.\n\n4. Never start projects until sufficiently planned and staffed. \n\n"Without an understanding of or visibility to the portfolio constraints, executives and other leaders step in to drive determination of budget \n\nand timeline that may or may not be achievable," says Keegan. Leverage the portfolio planning function to prioritize and sequence demand for \n\nas-a-service offerings. \n\n5. Create an effective gating mechanism prior to production. \n\n"A capability for owning service transition needs to be baked into the model to assure that what goes into production are only changes that \n\nare ready to be supported," Keegan says. Those responsible for these decisions should be independent, but aligned with both the build and run \n\nfunctions. \n\n"This capability owns the build-to-run boundary, making sure all is correct (to meet business needs), captured (so it can be reproduced, and \n\nreplicated), and supportable (so when phone calls reach the help desk, they know what to do). Whatever the change is, whenever it needs to be \n\ndeployed, the gate into production needs to first and foremost consider the ability of the run organization to support that change when it goes \n\nin."