Collaboration Essential Between Project Management and IT Architects

Information technology (IT) related projects, just like traditional design and construction efforts, are team activities. A variety of individuals and talents come together for a project and combine their efforts to produce a system or application. IT projects of a material size also are renowned for their relatively low success rate. While some of this can be attributed to the complexity of the undertaking, the root cause of many failed projects is leadership. The scale and diverse talent requirements of IT projects make trust and close collaboration between project management and IT architect leaders an essential ingredient to success.

INSIGHTS FROM THE PAST

In the early days of my career as a defense contractor, the “source material” for program/project managers (PMs) often was the technical ranks. In fact, management was the dominant career path for technicians at the time. Why was this? The nature of the work was large scale systems integration, often with much custom-coded software. The primary challenge was viewed as one of technology, not of planning and execution. Certainly planning, estimating, and execution were important, but the project management discipline was evolving and not so well appreciated as it is today.

These full-time IT engineers were drawn into management roles (often reluctantly) because they had demonstrated an ability to visualize and promote a coherent technical vision for solutions as a whole (not just their area of specialty), as well as planning and organizational skills with an ability to motivate/lead people.

It is interesting to note that some were technicians of modest technical skill who exhibited a higher aptitude for organizational tasks and leadership. This resulted in two distinct classes of PMs: those with better technical leadership skills and those with better organizational and execution leadership skills.

Nonetheless, PMs generally were expected to provide technical vision and mentoring, plus management of planning and execution for their initiatives. On larger programs, it was clear that these responsibilities were larger than one person, resulting in the appointment of a “deputy PM” at the program level and perhaps additional subordinate managers as well.

Over time, a pattern emerged among successful programs/projects and those that failed. The most consistently successful projects combined a strong technical leader with a strong administrative leader. One focused on keeping the technical design and construction consistent with client objectives and internally sound, while the other maintained and tracked delivery progress to the plan. Most importantly, the two formed a cohesive and mutually supportive team—developing plans together, recognizing the strengths and weaknesses of each, and presenting a unified face for their project team.

WHERE THINGS STAND TODAY

Through the intervening years, we have witnessed the development of a highly refined PM body of knowledge and recognition of PM as a distinct discipline, accompanied by the rise of a professional PM corps with guiding standards and professional certifications. In the same period, technology has rapidly evolved toward component architectures and a shift in emphasis from large scale development to integration of standard components. The technical disciplines have evolved as well, with an emerging body of knowledge around IT architecture. As software, hardware, and systems become more and more complex, the need for IT architects continues to grow and the discipline continues to mature.

While the industry as a whole has benefitted from these trends, we still find a high incidence of IT projects that fail to live up to expectations. The success rate has gone up but is nowhere near what most would consider acceptable. Certainly the reasons for this are varied, and there is no one factor that explains the ongoing issues.

Ironically, the great strides in formalizing the PM discipline and creating a professional project management corps may have had an unintended side effect. The specialization of PMs and technicians has tended to distance them from each other and fragment their project contributions. While in the past, insufficient attention was given to process adherence and effective administrative management, perhaps the pendulum has swung too far in the other direction.

Some professional project managers seem to feel if they only execute the standard process faithfully and produce the required artifacts, a good result will ensue. Similarly, many technicians believe that if we just get the components right, with well-defined interfaces, these will automatically work in harmony when assembled into the total solution. Common sense would indicate that judgment, adaptability, and attention to the whole are necessary .

PITFALLS TO WATCH FOR AND HOW TO AVOID THEM

As an industry, we are not yet able to execute IT projects with a reasonable expectation of success. One means of addressing this is to ensure that technical and administrative interests are both well represented and well coordinated. What are some leading indicators of a PM/architect dynamic that is likely to take a project off track?

• Lack of leadership authority vested in PMs and IT architects: Some of the worst project disasters happen when no one is clearly in charge or when project “leaders” carry responsibility and accountability, but without appropriate authority. Sometimes this is a side effect of staffing projects from matrix organizations, with temporary work assignments, and no allocation of line authority for the project. Recognize that both the PM and the architect require authority to be successful. Trust your leaders to exercise authority—or replace them with someone you can trust. Grant your managers the authority they need, and avoid misunderstandings by clearly defining the leadership structure. Depending on the nature of the project, either the PM or the architect can be the senior leader, with the other serving as deputy. Both models have been observed to work well.
   
• PM and IT architect not a cohesive coleadership team: The architect bridges concept and technology, while the PM owns logistics for bringing the solution to reality, but they must stand together to confront the many challenges to project success. When PMs and architects have not worked together before, they may find themselves at odds over many decisions, partially because the performance criteria for these roles are different. To simplify, the PM is evaluated by on-time and on-budget metrics, while the architect is evaluated by the business value of the solution. It is crucial for senior management to recognize the challenges, set clear expectations for cooperation, and support development of a close-working relationship.
   
• IT architect engaged too late: The most egregious mistakes tend to happen in the earliest phases of a project. In many cases (particularly if there is a PM “pool” in your organization), the PM may not have significant domain experience with the business problem, or with the likely technology solution. This does not negate the value of the PM, but it highlights the need for the PM to have a trusted IT architect “wingman” at the earliest stages of the project. The architect should have continuity with the business problem and the surrounding “ecosystem,” formulate the unifying technical vision, and be the technical driving force.
   
• Inadequate dialogue with business representatives: It is the architect’s job, along with the PM, to gain a thorough understanding of the business leader’s needs and expectations through a continual, ongoing dialogue, and translate these into a coherent vision for the project team. A good architect is able to challenge the program definition, schedule, and budget, by understanding both the business problem domain and the possible technology solutions that can address it. The architect and PM together should be able to look beyond the stated desires of the business leader, developing and suggesting alternative courses of action that the business may not have known were possible. Be sure that your PMs and architects understand the necessity of working together to build a healthy dialogue with the business.

CONCLUSION

A project of material size requires both disciplined administration and a clear technical vision. The PM is responsible for project success, while the architect is responsible for the overall quality and fit of the solution. More importantly, there is an absolute mutual dependency between the two roles to achieve success. To summarize, here are some of the other critical points toward creating successful project leadership teams:

• PMs and IT architects together represent the critical mass of administrative, domain, and technical leadership for a comprehensive approach to project success.
   
• Trust your PM and IT leaders, giving them the authority, backing, and tools they need. Either trust them, or replace them with someone you can trust
   
• The IT architect and the PM must cultivate a close-working relationship with each other and with business sponsors.
   
• Analytical tools, process standards, and technology standards are essential but recognize that individuals and judgment matter.
   
• Large IT projects are complicated, difficult, and highly variable. Experience, creativity, judgment, and leadership still play a role, perhaps now more than ever. A complementary blend of talented technical and talented administrative leadership is one part of the solution.

by Bradley Rhine, co-founder and CEO of Cogentes, an enterprise technology and business consulting firm.