As part of the series discussing potential organizational strucutres for IT, the Development organization must be understood as a strategic partner to the business. One way to think about it is that Operations is focused on the immediacy of today while Development drives the effectiveness of tomorrow. Development keeps the business in tune with the market and the company’s future direction.
Superficially, this can make it sound like Development is simpler to manage than Operations, but it requires a different mindset than found in many Development organizations. Many either isolate the developers from the business (to keep them focused on that all-important code), others fracture the development staff so that they are almost part of the lines of business and are ultimately reactive. In my view, developers should be organized into functional groups that either support each line of business (silos) or by technology (such as a Mobile Applications group and a Portals group). Each has its benefits (discussed below).
How does this not fall into the two traps I mentioned? By adding a Portfolio Management Office function. The weaker the PMO, the more strongly aligned to the business the development organization needs to be. With a true center of excellence in portfolio management, the development silos can break down and become technology centers of excellence.
My diagram shows Portfolio, Program, and Project management. So, just what is the distinction? Project and Program management is fairly commonly understood – the simplest definition of a program is a series of projects. But it has been (well) said that the distinction between Project/Program management and Portfolio Management is the difference between doing things right and doing the right things. The PMO also contains Business and Systems Analysts who drive the acquisition of requirements from the business units. There will be more in a later post that I will devote to the PMO.
Enterprise Architecture is what prevents the rest of the development groups from devolving into silos and fiefdoms. This group drives down the accumulation of technology debt by preventing bad decisions, promotes reuse and modular architecture, and ensures that systems have broad use across the enterprise rather than serving the needs of a narrow constituency.
A word on frameworks at this stage. Just as Operations is the “home” of ITIL, CMMi, and Six Sigma, Development is the home of PMI’s framework (in the PMO) and TOGAF (in Enterprise Architecture). More on this later as well.
An obvious question at this point: Agile or Waterfall? This post is already too long so I will address that in another post. Purists will be disappointed.
Let me pose a question to the audience: Should the development staff be organized along lines of business as subject matter experts, or by technology competency so they provide shared expert services across the business? Conceptually, I favor the latter, though I have only seen it work properly in software development companies where they produce software for sale. In that case, technological talent is more important than deep subject matter expertise – it is the designers who must understand the business, not the developers. Is it impossible to use this model where IT supports the main function of the business and is not producing the product for resale?