Showing posts with label activities. Show all posts
Showing posts with label activities. Show all posts

Tuesday, September 22, 2015

Framework Flexibility - From CLAP to CLIP



As many readers may have noticed, there are some fairly significant gaps in the CLAP Framework. In the perfect world, it is really intended as a guide for how to execute Business Goals into practical IT Projects. But there  may be some flexibility in the simplicity of that framework.

A colleague pointed out that maybe the missing component wasn't necessarily the Application, as those needs are covered off in the Functional Requirements. He suggested that instead the framework should consider the Information Architecture itself.

For the purposes of this framework, lets consider that data is the raw input of a process, and information is the output. Information needs to have a defined structure and each element has a distinct meaning. Consider the difference between distance an speed. Distance is a unit of measure, denoting how far something is. Speed is the distance divided by the time taken to travel the distance. Speed is the result of a process. applied to the data.

In the CLIP Framework, the notion of Information Architecture is added. It describes the processed data, its flow from system to system, and its attributes. For example, is information synchronous (live from a source) or asynchronous (delivered by a different process). Further, we see where the Requirements and Standards get applied, and how Security Requirements need to be considered through every step of the process.

Finally, we see the Validation step happens just before the solution is transitioned to Operations. It asks the question "Did the final physical solution deliver what was designed ?". Arguably, there is another validation step, which asks the question "Does the Solution Architecture satisfy all of the requirements ?".

The validation is key, as this largely waterfall process needs to map the entire solution all the way back to the original Business Activities, described in the functional & non-functional requirements. As you can see, the framework is flexible enough to be applied to many IT Goals, and not so rigid as to be unmanageable.

Monday, September 14, 2015

RASCI for Project Decisions

When Enterprises embark on large projects, they build out a Project Team. This team consists of Stakeholders, Project Manager(s), EA, TA, SA, Implementation resources and Operations. The challenge happens when Project Decisions need to be made - who makes the call ?

Enter the RASCI. It is a matrix of the key roles, and who should be:
  • Responsible
  • Accountable
  • Supportive
  • Consulted
  • Informed
Assuming we use the RASCI members as defined in the PMLC, we would end up with a table like this:


Stakeholders
Project Manager
Business Analyst
Enterprise Architect
Solutions Architect
Technical Architect
CoE
Operations
Budget 
R
A
S
C
I



Timeline
R
A
S
S
S
I


RACI
I
R
I
I
I
I
I

Project Charter
A
R
S
S
C
I
I
I
Project Plan
A
R
S
S
S
S
C
I
Functional Requirements
I
I
R
A
A
A
C
I
Non-Fuctional Requirements
I
I
R
A
A
A
C
I
Conceptual Acrhitecture

I
S
R
A
A
C
I
Logical Architecture


I
S
R
A
C
I
Physical Architecture



I
S
R
A
I
Detailed Build Plans




I
S
R
A
Runbooks & SOP





I
A
R
Now that the "theory" is out of the way, let's take a look at a practical example:

The project is building out network infrastructure to support a new group being added to the Enterprise. So possible questions which might arise are:
  1. A Stakeholder doesn't want to change the Firewall Rules. Who is authoritative ?
    • The Technical Architect "owns" the Physical Architecture, including decisions about their use & configuration
  2. Who should be informed of a change in Project Scope ?
    • Since the Scope is part of the Project Charter, the Project Manager is responsible to inform every role on the RASCI with a corresponding letter in the matrix. So everybody.
  3. What is the role of the BA in the Detailed Build Plans ?
    • None - there is no corresponding letter in the matrix
As you can see, the roles & responsibilities are clearly defined, so that everybody on the project can determine who "owns" the decision. That's not to say that the project Stakeholders won't over-rule some decisions, but in general they don't.