Andy Thorburn - Change Management :: Content Marketing :: Skipper
  • Business Blogs
    • Change Management
    • Content Marketing
  • Personal Blogs
    • Yacht Racing
    • Personal Photography

Product Owner - why we do the stuff we do

12/8/2016

0 Comments

 
The following passed around by a colleague as an aide memoir
Picture
0 Comments

Risk Management in context of Disaster Recovery

16/4/2015

0 Comments

 
(Notes provided recently to a colleague explaining how to approach the management of Risk.  The context is Business Continuity for a client where the client lead only considered Disaster Recovery as the solution.)

--Quote--
Think of DR in terms of a treatment for a specific risk.

A risk = something that might happen.  If it does happen then we need to take action to resolve (what has then become) an *issue*.

The RISK is that “our systems will break therefore we will no longer be able to operate”.  (Ie a Business Continuity (BC) risk in this instance).

As with all risks facing a business, there are always a number of ways to deal with each risk (so that it does not become an issue).

These “treatments” are valid at all levels within a business (project, programme, business unit or strategic) and why most Project / Programme managers are taught about managing risks within their transformation initiatives.

CRAPT is how I remember them:
  • Contingency
  • Reduction
  • Accept
  • Prevent
  • Transfer
Remember: nearly every risk can be treated in more than one way.  You have options. 

Let’s look at each one.

Contingency
Essentially, “a back up plan”.  If this risk becomes an issue then we will take this course of action.
In BC-terms this could be your DR plan:  close down one system and start up another.

Reduction
We will reduce the likelihood of the risk becoming an issue (and “hope” we never have to deal with the issue).
In BC-terms this means using monitoring / early-warning systems to alert us to eg
  • How close we are to capacity
  • Speed of responses from servers as indicator of normal/peak running
  • Intruder detection, etc, etc

Accept
We will accept that this risk might become an issue but have decided we can deal with the consequences.

Such an approach is valid if the costs of recovering from the issue are sigificantly lower than the cost of managing the risk.

In BC terms an example could be: in order to continue business with no interruption we need an entirely replicated parallel system ready to go.  The risk is that it will not perform at the same speed.  Having a same-speed system waiting in the wings will be very expensive, therefore I will *accept* there may be lower speed and deal with the consequences.

Prevent
We will take whatever measures necessary to prevent the issue becoming an issue.
Often a high cost option and sometimes impossible. 

In BC terms, I suppose you could prevent usage-based server outage by automatically killing non-essential processes as load increases.

In doing so, you prevent the risk becoming an issue, albeit with sacrifice elsewhere.

Transfer
As near as you can get to a “not-my-problem” solution.  In project terms:  I have identified a risk to my project - a pile of unexpected work.  This risks my budget and timeframe.  However, I could fire up another project team to do that work and merge our 2 projects later on.  Therefore, I have transferred the risk to someone else.

In BC-terms:  I can transfer the burden of worry to another party.  They will manage the risk (probably using the other treatments described above), communicating back to us the threat level for the risk becoming an issue.  Client therefore manages a contract rather than the work required to manage the risk or the issue.

 
Other comments regarding risk management:
“Ignore” is never, ever a valid treatment
“Mitigate” – a catch all term.  In fact it really is only one valid treatment (“Reduce”).

Picture
Picture
0 Comments

The price of change - ERP Implementation - enterprise level

28/10/2014

0 Comments

 
Excellent paper - produced annually, comparing Oracle vs SAP vs MS Dynamics.

Highlights (or, more accurately, low-lights): 
  • Project costs average $2m or average 3% of the implementing companies revenue
  • Payback generally within 2 years
  • Less than 30% of companies realised at least half the financial benefits they expected


Read the report here - all (c) Panorama Consulting
0 Comments

Change Management - Leadership

29/7/2014

0 Comments

 
At Portfolio and Programme levels, leadership (rather than management) starts to come in to focus.

The infographic (right) is a good distillation of required qualities and behaviours, however, I'd prefer to label the columns as "Managers" on the left and "Leaders" on the right.

To me, Leadership has not changed over the decades.  The workplace has not changed.  We always have (and always will) need both managers and leaders. 

Managers "push" people along, Leaders attract followers.

Managers concentrate on the "Who" and How",  leaders on the "What" and "Why".
Managers qualities vs Leaders Qualities
Click to enlarge
0 Comments

PMO - Infographic

29/7/2014

0 Comments

 
0 Comments

The relationship (differences) between Portfolio, Programme and Project Management

17/7/2014

1 Comment

 
During the last 2 weeks, twice I have been asked to explain the differences between these three "levels" of Change Management.

One of those for whom I needed to explain the difference was a Recruitment Consultant who "specialises in project management".  Slightly worrying.  I hope he doesn't confuse Daily Rates as well.

For 2-3 years now I have carried around a number of laminated graphics which help explain concepts that many of us use daily but are alien to others.  One of these this Venn diagram, the work of Jerry Buckoff which I accompany with the following description:

Relationship between Projects, Programmes & Portfolios
Click to enlarge
Projects
  • Deliver against a Definition of Requirements and a Business Case
  • Clear start, clear end, clear deliverables 
  • Focus on time, cost and quality
  • A temporary "structure"

Programmes
  • Deliver against a Vision and a Benefits Realisation Plan
  • Phasing (or Tranches) are likely but time is less important 
  • Likely to comprise a number of projects which may (or may not) be inter-dependent
  • Focus is on delivering benefits to the Stakeholders for the business
  • A temporary structure (lasting as long as it takes to deliver the benefits required by the Vision)

Portfolio
  • More strategic, closer to the Executive Team
  • Alignment of Programmes / other change initiatives with business / enterprise goals
  • Portfolio is assessed on the aggregate value of its constituent initiatives
  • A permanent structure
Relationship between Project, Programme and PortfolioClick to Enlarge



Practical representation of the hierarchy 

1 Comment

Some docs that I find myself often referring to

15/7/2014

 
the_equation_for_change.xlsx
File Size: 10 kb
File Type: xlsx
Download File

prog_mgt_overview_diagram.pdf
File Size: 29 kb
File Type: pdf
Download File

waterfall_model.pdf
File Size: 11 kb
File Type: pdf
Download File

Picture

Coming Soon...

11/7/2014

0 Comments

 
I'm working on a number of articles.  I'll post them here as soon as I am reasonably happy with them:

  • Distinctions between Portfolio, Programme and Project Management
  • Handling Risk within change initiatives
  • Linear or Cyclical Methodologies
  • Handling Project Failures
0 Comments
    View my profile on LinkedIn

    Change Management

    Portfolio :: Programme :: Project :: Transformation :: Change

    Picture
    Follow Andy's board Change (Portfolio & Programme) Management on Pinterest.

    Archives

    August 2016
    April 2015
    October 2014
    July 2014

    Categories

    All
    Change Management
    Leadership
    Portfolio Managment
    Programme Management
    Project Management

    RSS Feed

Powered by Create your own unique website with customizable templates.