Mark Kraieski, Chief Architect (chiefarchitect@virima.com)

Question: How should we organize our architects for successful project delivery?

 This is a trick question, right? If your projects are failing today, reorganizing your architects, or your whole IT organization, or your sock drawer, will likely not, in and of itself, make your projects suddenly successful. IT managers reach all too quickly and frequently for their Org Chart Randomizer (yes, there is an app for that) when unable to meet the demands and commitments facing them. This step in the Management Life Cycle usually comes right after “Blame Predecessor and Peers”, and just before URAMO (Update Resume And Move On).  IT managers often reorganize and restructure without first really understanding why their projects and organizations aren’t successful. But let’s hold all of that for a future question, and I’ll try to answer the one that was actually asked.

Let’s look at the different elements of “organizational structure” that come into play. First, we have “The HR Org Chart”. This is usually what we are referring to when we want to reorganize – who reports to whom and who lives where, who pays for my laptop, who creates my review and approves my vacation, who will tell my cubicle mate he/she needs to use some deodorant, and what is the scope and purpose for my group. This component of organizational structure seldom aligns with real project structure and causes projects to be parceled up and the bits shoved out across the org structure (matrixed). Too often the various organizational entities are more focused and skilled at how to protect themselves from project failures than on how to ensure project successes. Unless you are a smaller start-up with well-defined projects, you will likely have to matrix projects across the org structure. How you organize these groups is not nearly as important as how you prioritize, measure, and reward overall project success within each of them.

The second organizational element to look at is “Communities”. If your IT shop is of moderate size, you will have specific skill sets present in multiple places across the organization. For example, architects, Java developers, QA analysts, system administrators, network engineers – all might appear in several places in the org chart. To consistently deliver successful IT projects each of these communities of skills (sometimes organized into “centers of excellence” though rarely being so) must have a community leader who ensures the community defines and evolves standards, best practices, processes, artifacts, certifications, and knowledge. Otherwise the disparate groups with the same skill set will work and perform very differently. Effective technology communities are a force multiplier, increasing productivity, consistency, and repeatability.

The final organizational element is “Project Structure”. High performing IT organizations are focused on successful project delivery, not just on great org charts and centers of excellence. It must all come together at project time. Focus the resources from the org structure and technology communities on defined project deliverables, and protect them from organizational chaos, confusion, malaise, and subterfuge – let them deliver. Recent IT project management trends such as Agile and DevOps attempt to do exactly this. I hate to call them “recent” since they are more a reflection of how successful project teams have worked for years. This intense project focus, “gazelle intensity” in Dave Ramsey speak (as if your life depends on it), can transcend organizational and community inefficiencies.

So, back to the original question. How should we organize our architects for successful project delivery? If you want successful projects, how you organize your architects is not nearly as important as having competent architects that are keenly focused on project delivery, with significant skin in the game (accountability). “Drive-by Architecture”, where the architect descends his lofty mount, critiques and chastises, and then resumes basking in the high altitude sun far from the ramifications of project failure, does not work and has never worked. Architects are and must be part of the project team first and part of the organization second. If you want to centralize your architects, that is fine. If you want them distributed and communitized (yes, I made that word up), that is fine. Both will work. So will a hybrid model. But, whether they are working on one or many projects, architects must be active and accountable members of those project teams from start to finish, working with intensity to ensure project success.