Recently, project managers’ roles have changed; they’re responsible for more than mere project delivery of projects, they’re responsibilities now also include important issues such as compliance to project controls and audit requirements such as SOX, HIPPA, and many industry-specific regulations. These additional responsibilities complicate the delivery process and burden project managers.
IT project managers typically come from different backgrounds. Some project managers have development backgrounds, and can understand the technical issues and help resolve them. However, the constant changes to technology quickly make the technical skills of any project manager outdated. Soon, the project manager loses the ability to understand the technical issues, and instead must rely on other technical resources in the team. The problem arises when a project has not been structured with the relevant technical resources. In such cases the project manager will get inaccurate advice about resolving the issues. The problem is even more aggravated for project managers who come from non-technical background.
This article demonstrates how to pair a project manager with a technical representative such as an architect or tech lead to guarantee project delivery when no formal architectural role exists.
The ideas presented here are easily achieved by IT organizations that have a formal Project Management Office (PMO) and consistency in architecture applicability. Smaller or less formal IT groups that do not have either a PMO or consistent architecture practices can benefit more by combining the ideas presented in this article with the establishment of such practices.
| Author’s Note: See the article “Architectural Layers and Tips on how to Achieve Architecture Consistency” for more information about organizing the different architectural roles and attaining consistent architecture. |
Partnership
IT groups employ architects to play a senior guiding role for technical solutions. When the architect’s role is not formalized (typical in smaller organizations), a senior developer or tech lead typically fulfills the need to direct the solution design. Irrespective of an IT organization’s size, the project manager has a main role in project delivery, and usually acts as the single point of contact for any given project.
Organizations expect project managers to get specialized help or resources to solve problems in specific problem areas. In fact, this is where problems usually occur, because the project manager may not have sufficient understanding of the problem to get the specialized help needed. Present-day projects vary in complexity, requiring different technical skills to solve problems; specific knowledge to forecast delivery timelines accurately or communicate realistic expectations to the customer (or business) about solution delivery. Table 1 illustrates some examples.
| Complexity | Critical Technical Issues |
| Delivering strategic initiatives such as Global ERP or Supply Chain Replacement |
|
| Replacing legacy applications with updated technologies—either with custom solutions or a COTS solution |
|
| Infrastructure improvement or replacement, such as installing routers, upgrading hardware, or making operations center changes, etc. |
|
| Key strategic releases for any IT products, such as in health care or banking |
|
Even though the examples shown in Table 1 are not exhaustive, they illustrate the complex situations where IT needs reinforcement for project leadership. Such proposed partnerships will bring the specific expertise onboard (such as for those illustrated in Table 1) to help the project manager achieve success.
Partnering
In organizations with formal architect roles, the technology expertise comes from the architecture group. Therefore, bringing the architect in at the inception or planning stage to partner with the project manager can help in creating the overall project plan, which will then have properly thought out tasks and dependencies to deliver the solution.
At the same time, resource contention is a real issue in development organizations, so be careful when creating this kind of partnership. Some suggestions that can help are:
Figure 1. Shared Responsibilities: The figure shows typical task responsibilities from a project delivery perspective shared between a project manager and an architect.
- From the project delivery stand point, the solution architect (or tech lead) should come from the delivery group.
- The project manager can be from the PMO or from development groups. Many large organizations tend to have a PMO that acts as a third pillar (sometimes combined with QA), the other two are a development or delivery group and an infrastructure group.
- For large initiatives, IT organizations need to be careful when procuring architectural capabilities. Sometimes, instituting an internal program and promoting an existing senior technical staffer to an architect’s role can be more fruitful (provided that the architecture group is willing to offer a proper mentoring process).
- For smaller projects, such as minor releases, bug fixes, or small enhancements, the architectural responsibilities can be delegated to a senior developer. Such opportunities are useful for training senior developers to play the architect role.
- IT needs to establish a way to measure the success of this partnership, and a constant monitoring process to make it more effective and localized.
This process typically happens during the strategy phase of the overall process. It also helps ensure that IT has the right tools (or establishes the need to procure those tools) as part of implementing new initiatives. It’s important to involve architecture to resolve any issues before an initiative is approved. Typically, enterprise architects get involved at this phase. If no process exists, it’s the responsibility of IT to make sure that architecture groups get involved.
Program Management and Project Management
Program management usually consists of several projects or sometimes just one project (for very large initiatives, such as an ERP implementation). A program manager handles these projects or the large implementation. Despite the two terms, there’s generally little difference between program management and project management except for scope and size. Budget management is often the biggest difference; operational differences are usually the same between these two management practices.
Program management and project management are the management phases where the planning for budget and delivery of the solution takes place. The best option for partnering with a program manager or project manager is to use the same enterprise architect who’s involved at the strategy or Portfolio Management phase. After the projects progress beyond the inception or planning phase, the solution architect will become more involved, and can work with an enterprise architect to use established standards and processes to deliver the project.
Sphere of Influence and Objective Measurements
Figure 3. Spheres of Influence: The figure provides a complete overview of the partnership arrangements at each management stage.
Figure 3 provides a different perspective on the partnership arrangement at each management stage, and how those align with the project delivery from strategy to delivery. Portfolio Management requires a complete overview of every aspect of delivery.
The project execution responsibility such as program or project management comes from overall IT; it can be PMO or from any delivery group. It is usually the responsibility of project manager to feed the information that is required for the completion of any measurements such as ROI, cost analysis but the justification will be thorough with the help of an architect. Since either enterprise architect or solution architect (with the mentoring of enterprise architect) will participate from the strategy stage to the delivery phase, completing the measurement metrics will be easy and also be more consistent.
Extending the Partnership
After a solid partnership between management and technological expertise has been put in place, organizations can extend the concept by including a business resource as part of the partnership; however, it is important to establish a prior partnership between PM and Architect before including the business resource in that partnership. This delay enables IT to iron out the process issues before bringing in the business resource.
The addition of business resource will provide the following advantages:
- Tighten the project requirement process, because it’s the business’s responsibility to make sure the requirements are properly reviewed and signed off.
- Reduce complaints from business that IT is not catering to the business needs or IT is not delivering what business wanted.
- Bring better perspective in terms of business direction, which enables architects to design for the future (take care not to focus too much on this aspect).
- Provides a great opportunity to establish business architecture and make processes such as BPM (Business Process Management) or BPMN part of the organizational standards to achieve consistency across the organization.
- Help to convey messages in ways that businesspeople can understand.
The idea of partnering has long existed in some parts of IT industry. Adopting the partnership approach described in this article will help to identify and resolve issues at appropriate times. IT organizations should probably expect to take some time to formalize the process of transformation from one of identifying the project manager as the only responsible resource for the delivery of a project to a full partnership of project manager and architect. Using the tips and suggestions for organizing the responsibilities between project manager and architect presented here, building such a partnership will definitely help guarantee the delivery of projects of any size and complexity.
