Planning a project – the TOGAF way

Posted by Udayan Banerjee on February 2, 2011 · 15 Comments 

If you have no intention of adopting TOGAF then does it make any sense for you to understand how TOGAF recommends planning a project? I think the answer is yes if somebody can explain it in simple terms. Since TOGAF is flexible and it recommends many techniques which you might find useful and apply in isolation, it may make sense for you to glance through these series of posts. (In this post I am talking about a technique of Stakeholder Analysis)

As we had seen earlier, the heart of the “TOGAF – ADM” is how you define the work that needs to be done. It is done from “Phase A” to “Phase F” in a top-down manor. (See my earlier post – What is TOGAF – without jargon for an overview)

In the last post we had seen that TOGAF – ADM consists of 4 major steps. I had grouped 6 phases of ADM to call it the second step. Now let me logically break this step into 3 sub steps.

1. Tailor TOGAF to suit your need
   
2. Define scope of work and prepare plan for rollout
   1. Define the scope and get approval from the sponsor
      
   2. Define requirement in terms of how the business process will change, what data, application and technical infrastructure is required for accomplishing the work – this step consists of 3 distinct phases
      
   3. Select a suitable solution and make the implementation plan – this step is also made of 2 ADM phases
      
3. Oversee development and implementation
   
4. Manage post-implementation change
   

Define scope and get approval

[Phase A: Architecture Vision]

“…defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals…”

“Architecture Vision” means a description of where we want to be. It is to be used, among others things, to help the sponsor to sell the project to stakeholders and decision-makers.

“…it describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented…”

“New capability” in this context means whatever the enterprise will be able to do after the project is implemented which is not possible today.

Define requirement

[Phase B to Phase D]

The following table indicates what TOGAF means when it talks about different types of architecture:

Business Architecture	The business strategy, governance, organization, and key business processes.
Data Architecture	The structure of an organization’s logical and physical data assets and data management resources.
Application Architecture	A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
Technology Architecture	The software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.

In this step you need to define, in these four dimensions, where you are (baseline), where you want to be (target) and what the gap is.

Select solution and make implementation plan

[Phase E & Phase F]

This is where you get into specific – select the actual technology – decide on make vs. buy. Here, you group requirements into specific projects, access priorities, identify dependencies and prepare the project plan. You also need to ensure that your plan is in sync with other organizational initiatives. You also will do a cost-benefit analysis of individual projects.

Stakeholders

Identifying the stakeholders, explaining to them what you are planning to achieve and getting their buy-in is a critical theme which runs across these phases. It is somewhat like the saying that “justice should only be done but should appear to be done”. You should not only plan to create a more efficient organization but everybody who matters should be convinced about it.

To achieve this you need to do the following:

• Know who the stakeholders are
• Understand their concerns
• Identify how your solution is going to address their concerns
• Create suitable documents which will explain the specific aspect of the solution that is of interest to the stakeholder – in TOGAF term it is called “Selecting a Viewpoint“

We will examine Viewpoint in more detail in subsequent post.

TOGAF recommends a technique for stakeholder analysis where you produce a document like this:

Stakeholder Group	Stakeholder	Ability to Disrupt the Change	Current Understanding	Required Understanding	Current Commitment	Required Commitment	Required Support
CIO	Smith	H	M	H	L	M	H
CFO	Brown	M	M	M	L	M	M

This analysis can be extremely useful. Unfortunately, this document cannot be shared – it has to be kept away from all the stakeholders. If you are an external consultant it may be easier to maintain the secracy.

In the next post I will get into more detail of how you go about defining requirement, what techniques it recomends and how much flexibility you have remaining within the TOGAF framework. I will also follow this up with more details on each individual phases.

Udayan Banerjee on Google+

Filed under Architecture, TOGAF · Tagged with Application Architecture, Architecture Vision, Business Architecture, Data Architecture, NIIT Technologies, Stakeholder, Stakeholder Analysis, Technology Architecture