Enterprise architecture brings end-to-end visibility of the value chain that cuts through departmental boundaries. This enables the organisation to launch targeted projects to address pain points and push through improvements. With an established enterprise architecture capability, the process of taking ideas and building them into project definitions will change. The project office will no longer serve as the first place to go in order to obtain the resources to perform the initial analysis. Instead, the business will turn to enterprise architects in the first instance. The project management role will move further away from change definition and be more firmly fixed in change delivery.
Projects come to life in many different ways but fundamentally they are all based on the need for change. The drivers for change may come from strategy, competitive threats, market opportunities, compliance needs and a host of other sources. Business leaders have to handle the resulting barrage of requests for change and they don’t have the time to address them all.
So, to whom should they turn to undertake the detail analysis and ground work to produce the justification and to establish a project to deliver the change they consider will address the requirements and deliver the intended business benefits? Where are they going to get the resources to analyse the issue, devise a solution and come up with what needs to be done? Only after these steps have been undertaken can they assess the business case and the impact and decide if this activity should be carried out along with which of the solution option to select.
The traditional project is there to deliver the selected option after it has been clearly defined and agreed. Execution is the strength of project management. But so much of project time is taken up in the preliminary steps of shaping and agreeing the project; getting from the original requirement through all the steps to a clear definition.
With the establishment in most organisations of a maturing project management office (PMO), business managers have come to rely on taking their idea (mandate) along to the PMO to obtain resources to address these initial steps. A project manager and maybe a business analyst are assigned and the requirements and solution are marshalled into a project definition and submitted for approval.
The Change Overload Headache
With multiple projects bringing individual changes, what happens to the user department that has to accept the changes coming from the individually run projects?
As an example, let us take the finance department, which is not the direct target for a new system but has to adopt new ways of working because of the change that has been delivered by Project X. Then along comes Project Y and Z. All projects are pushing to deliver and are vying for the finance department’s time, resources and understanding.
The finance department’s management team, who already have their day-to-day tasks to perform, are now left to absorb the disparate changes and adapt to the different timelines, intents and styles of delivery from the competing delivery projects.
They understand the strategic nature of the projects and how they will benefit the organisation but still feel these changes have not been organised in a coordinated approach that accounts for their operational processes and schedules.
Is there an alternative? How can an organisation coordinate the project deliverables and changes to take into account each of the impacted areas of the organisation?
The answer lies in the way the projects were first envisaged, defined and commissioned.
From Light Bulb to Kick Off
“The Change Overload Headache” describes just one example of the problems that can arise with the conventional method of transitioning light bulb ideas into projects that are ready to be approved and delivered. Most changes start off as an idea, which is then established as an initiative (not yet a project) that will forge a single path through all the other activities currently going on in the organisation. These can be other change activities or business as usual, but they form a formidable force against allowing breathing space for the new initiative to take root.
This is the initiation phase where the idea is vying for attention. The managers and teams, who are already fully loaded with existing approved projects and business as usual activities, are being asked for yet more time to consider this new project proposal. And without them the project deliverables will be ill considered and the whole project will get off to a rocky start when approved. However, with strong management backing, an initiative can take on a life of its own with the assumption that some higher authority or senior manager will somehow ensure it will work together with every other initiative for the greater good. The initiative becomes focused on the justification for the delivery of the individual project goal.
At this point it has yet to be seen if this initiative will slot into the overall strategic plan for the organisation. The priority, budget, resources and ability to absorb change aspects are the concerns of the initiating business and not the project team at this time.
After the initial requirements have been gathered and the initiative has been shaped into a business case, the new project is presented for approval. Like the instigator that created the mandate at the beginning it is the role of the approvers to ensure that this work somehow fits into the overall strategic plan for the organisation. The methodology they employ to perform this task, and how rigorously it is applied, will vary from management team to management team.
After the program or project has been approved by the management team, the committed resources will commence their work on the project. It is only at this point that the architecture and analysis for the solution will be brought together as parts of the project activity. By this stage, the company’s commitment and funds have been established. Any changes to how the solution is to be delivered now will become a political minefield. Requests for small changes are handled through the normal project change control but the demand of larger changes, or even questioning the need for the project at all, could become a matter of job security.
Under this approach, even in the best managed organisations, it is only when the projects progress through the execution phase that the cracks start to appear. Project teams are driven to succeed and project boards are competing for resources. The projects jostle for prominence with each project pushing its own agenda. There is still a need for coordination of all change across the whole enterprise.
This practise of launching more and more projects without oversight coordination is now being challenged by the up and coming function of enterprise architecture.
The Rise and Rise of Enterprise Architecture
Enterprise architecture (EA) is starting to become the foundation point for business change. Many organisations have some form of architect team but few have truly evolved that function to encompass the whole enterprise architecture capability. There are two main approaches to EA: The Open Group Architecture Framework (TOGAF) and Zachman. Although they have some differences, they are aligned in many ways.
The core principle is to address the requirements for change from the business, then data, then application and technology. To architect the business first provides a clear understanding of the target state, the transition, the benefits that will be accrued and the business case for the change. The necessary changes to data architecture can easily follow from the business level and the required changes to the application and technology layers is based on a firm foundation of understanding the benefits. Although the target architecture is produced iteratively around the capturing of requirements at all levels, the result builds a strong understanding of the need for change and how this links to the strategic direction of the enterprise.
A roadmap is produced from the gap analysis between the ‘as-is’ state and the ‘target’ state and, very importantly, the architect will assess the ability of the organisation to absorb change. This focus on the transition is key to the success of using an architect based approach and flows directly into the consideration of all change as part of the wider view of parallel activities across the organisation.
The architecture framework will further define change implementation possibilities and opportunities, and these naturally lead to defining the activities, usually programs, which need to be instigated to execute the change. The EA function then issues contracts to the PMO and others to undertake the delivery of the described and agreed change. The remaining aspects of the TOGAF framework provide for a continued governance and change control as future requirements and requests arise from either the strategy or business as usual running.
The Role of the PMO in an EA world
In most traditional organisations with a reasonably mature PMO function, the portfolio manager can be the first port of call when a need for change arises. The PMO will then progress the light-bulb idea through the standard steps to the point where there is a clear business case and approval for the project.
With the introduction of the EA model, the PMO enters the light-bulb-idea-to-project-start process at a much later stage than in the traditional PMO-led world that we described first.
With a mature EA function, the manager who is requesting a change does not seek out the PMO to get the ball rolling. Instead, they walk past the PMO department to the business enterprise architects. A request for work is defined and agreed and the EA team takes on the steps that lead to a well-defined, agreed architecture. This architecture not only takes into account the requested requirements but also considers all the other changes that would impact successful delivery of the benefits. The PMO has been repositioned from a role of definition-justification-delivery to the delivery-only role.
In organisations with a well-run and mature project portfolio combined with early involvement by the EA team, 3gamma’s experience is that projects become more tightly coupled around the strategic goals of the organisation with good visibility and all change appearing to come with a single origin and purpose.
Relieving that Change Headache
How does this change of process to include enterprise architecture as the first step affect the finance department, from the example above, who was bombarded with changes from multiple projects?
In the mature EA world her needs will have been considered as a part of the enterprise change roadmap and the impact on the finance capability map will have been assessed. The assessment will comprise all levels (business, data, application and technology) and includes the finance staff themselves.
Each of the enterprise architectures will have included an assessment of the ability of the organisation to absorb change. The finance team now have their roadmap and their schedule, which makes them feel part of the future instead of part of the problem.
With the EA governance function this understanding and care will continue throughout the lifecycle of the series of change projects and will adapt as new initiatives are raised.
In most organisations the project management discipline has been around much longer than enterprise architecture. And even in those organisations with an EA function, it is still maturing and getting established. Quite often it is focused on the application, data and technology levels—still seen as an IT function and part of a program or project. However, this is changing as the EA capability is breaking free from its roots in IT and increasingly is being perceived as a business function that will assist the organisation to realise the changes needed for success. As this evolution occurs, the PMO function can either try and fight it, or adapt to the new ways of working and together with EA enhance the ability of the organisation to handle change.