Framework = Solution (or not)

Framework = Solution (or not)


Best-practice frameworks are aptly named.  They are not complete solutions and as long as they carry the name 'framework', they never will be.

If we just had a framework for a house, could we live in it?  What about the walls, the furniture, the fittings, a door...?

Then, what is their real purpose?

These frameworks have been established with one common goal:   Guidance!

Let's say I was a busy IT Manager facing a particular challenge with projects that have been deemed failures because they do not meet customer expectations, even though they were delivered on time and on budget. 

How would I approach this situation?

Firstly I would begin by talking to the business and asking questions such as: 

1. Who is happy? (to determine what we are doing right)
2. Who is unhappy?
3. What are their expectations?
4. Did we identify the correct project stakeholders?
5. Were they involved in the project?
6. Did we define the correct project deliverables?
7. Did we ensure changing requirements were captured and met?
8. Did we perform user acceptance testing?

Through my investigations, I may have discovered that although the project deliverables were defined at the start of the project, by the time the project product was delivered, business requirements had changed.   I conclude that the project team needs a formal process for capturing changing business requirements and adapting the project scope accordingly.

If I had the time (which I don't), I could host various meetings and ensure that my project team came up with an appropriate solution.   But how long would that take?  Would we get it right first time?

Instead, I decide to refer to the appropriate frameworks for guidance (PRINCE2, PMP, P3O, MSP etc).  I look up the Change Management process and compare with my current solution.  After identifying the gaps, I create a suitable plan to revise my current process utilising the guidance from the framework.

Next, I would perform scenario-based tests with the business to ensure that the revised process meets the objective before going-live.

Once the process has been implemented and run for a predetermined amount of time (say a month), I would perform a post implementation assessment of relevant KPI measures and compare with my original baseline figures (to quantify the level of improvement).

Finally, I would report these measures to the business and confirm if their expectations had been met by the improvements.

So there you have it.  A practical approach as to how we should be utilising frameworks.  Be wary of staff or consultants who proclaim a framework is a solution in itself; or else you’ll be in for a few cold nights. ..

COBIT 5

COBIT 5

ISACA is in the news with about a major update to COBIT 4.1.  It seems the board at ISACA has been listening to the practitioners and is working on quite a major change.   The initiative charge from the Board of Directors is to “tie together and reinforce all ISACA knowledge assets with COBIT.”

They have put together a COBIT 5 Task Force, which includes:

• Experts from across the ISACA constituency groups

• Is co-chaired by John Lainhart (Past International President) and Derek Oliver (Past Chairman of the BMIS Development Committee)

• Reports to the Framework Committee and then the Knowledge Board 

The objective for COBIT 5 is to:

Provide a renewed and authoritative governance and management framework for enterprise information and related technology, building on the current widely recognized and accepted COBIT framework, linking together and reinforcing all other major ISACA frameworks and guidance such as

• Val IT 
• Risk IT
• BMIS
• ITAF
• Board Briefing            
• Taking Governance Forward
• Connect to other major frameworks and standards in the marketplace (ITIL, ISO standards, etc.)

Deliverables have been confirmed as:

·          

• An enterprise wide, “end-to-end” framework addressing governance and management of information and related technology
• The framework structure will include familiar components such as a domain/process model and other components such as governance/ management practices, RACI charts and inputs/ outputs.
• An initial COBIT 5 product architecture, specifying which types of “products” and other “guidance” that could be developed for specific IT professional audiences (e.g., assurance, security, risk) in support of enterprise business needs 

It all sounds rather exciting, although we will have to wait until 2012.....