Prince2 : 2009 Project Refresh

Although I've been following Andy Murray's blog on the Prince 2 Refresh Project, there hasn't really been much meat to it, in terms of understanding what this refresh really means for what we currently know as the Prince 2 project methodology.  According to his presentation (see link below) this was to protect crown copyright - okay... if you say so.  It seems now the time is right to reveal some of the content changes, and on the surface it sounds like a good thing.

In terms of structure there are now 7 Principles, 7 Themes (formerly components), and 7 Processes.

I like that they've gathered the principles that were scattered all over the book and reduced them down to 7 and that we can apply the test, 'Am I doing this? If not it isn't Prince2' to each.  Of the 7 (Business Justification, Roles & Responsibilities, Product Focus, Managed by Stages, Management of Risk, Scaling and Tailoring, and Learning Lessons) I find the latter a little curious.  Andy emphasised the need to learn from prior experience rather than simply identifying new lessons during a project and producing a report at the end.  It's not that I disagree with it - I just find it strange that it is important enough to be considered a 'principle'.

I'm pleased to see that 'Planning' has been removed as a single process and there is recognition that this goes on continuously throughout a project as well as major bouts of it at stage boundaries.  This is being addressed by including it as one of the 7 key themes (Business Case, Organisation, Plans, Risk, Progress, Quality, Issues & Changes) which all need to be continually present and reviewed throughout the project lifecycle.

We also wave goodbye to the 45 sub-processes (how I shall miss thee CS3...) and the 3 techniques (I never understood why these three were selected out of the many needed to run a successful project!).  Instead of sub-processes we will get un-coded activities and recommended actions.  In the case of techniques they rightly say they will refer to other Bodies of Knowledge, after all, why try to be all things to all people when other things exist?

Interestingly the number of management products has been cut from 36 to 25 based on what the authoring team consider to be a 'typical project'.  Andy didn't explain what this was so I am curious to find out.  What he did say was that we can scale up or down according to need.  Certainly when working with DSDM this will be scaling up!

It sounds like it's going in the right direction, it will be interesting to see how the pilots go and if they result in many alterations.  From my point of view I am particularly looking forward to the guidance for those directing a project as this is a real weak area.  All too often I see Project Board members who see their role as putting a name on a document for sign-off rather than having an active role and responsibilities.  Although as a project manager we can offer them guidance on what that should be - to have the fallback of Prince2:2009 Directing a Project guidance would be helpful.

Are you interested in the refresh? What's your take on it?

Source:

• Andy Murray's presentation of the project progress update at the International Congress for Project, Programme and Risk Management.
•  Copy of the slides for the presentation delivered above
• BCS article: Prince 2 exams set to be refreshed Q2: 2009
  

Lessons learned from President Obama's Inauguration Speech

I don't know about the rest of you but I found last week to be an inspiring week with much cause for reflection.  Witnessing the first african-american inaugurated as President of the United States is certainly one for the history books and therefore deserves a mention in this blog (I went home early to watch it live on TV).  There is a lot one can take from his speech an I wanted to draw your attention to a couple of things that are relevant to this project.

1. President Obama's message was very clear that each and every citizen has a responsibility to make a difference in order to bring about real change - "the price and the promise of citizenship".
   
   This is true of projects too.  Project organisations are temporary things setup purely to deliver a project.  Once that is done - it's up to the guys on the ground as well as operational management to make it a success and achieve the potential benefits.  Their continued efforts beyond the project is 'the price'; the potential benefits are 'the promise'.
   
   
2. "Today I say to you that the challenges we face are real.  They are serious and they are many.  They will not be met easily or in a short span of time.  But know this America:  They will be met."
   Some news channels reported the inauguration speech as being particularly grim in comparison to the campaign speeches.  Well of course it was!  Getting voted in is one thing and now he IS in he has to deliver.  Elements throughout his speech clearly intended to set people's expectations to realistic levels whilst still retaining a message of hope for the future. 
   
   Throughout the projects I've worked on I have always been very enthusiastic about what will be delivered.  I have learned the hard way of the real danger of my enthusiasm creating unrealistic expectations.  Therefore I have made a conscious effort on the project I am currently managing to constantly state that we will be unable to deliver all that we would like to by target date.  However what we will deliver will be the required elements and anything else is icing on the cake.  There is nothing wrong with a dose of realism (as I have to remind myself sometimes ;) ).

Are there any other lessons we can learn from his speech?

The path to CIO - as a black woman - to be or not to be?

The recent achievements of Lewis Hamilton and Barack Obama got me thinking about role models again.  Those of you who have been with me for awhile will know that I'm very interested in the challenges that women face working in IT and there is a lot of emphasis on role models.

It's a current ambition of mine to become a CIO and there just aren't that many females, let alone black females (the 'double whammy' as someone recently said to me).  So imagine my excitement awhile back on hearing the success of Gail Roper - a black female CIO working in US government.  Do you know of any others?

Anyway, back to my path.  My original plan to get there was to go through the ITSM route (which I really enjoy) yet recent events mean that I've had to put that plan aside and remap my path as I walk the project management route (which I also enjoy).  After some deliberation about the move I've decided that, actually, it is completely the right thing to have done.  Why?  Whether you read ITIL, CIO, or pretty much any other technology (with career focus) website out there; there are constant references to 'the business'.  Alignment.  Integration.  That's where we are at.  So what better move for me than to step out of IT and into the business in order to get a better understanding of 'the other side' with which we are to integrate?

More on this subject another time.  For those that would say race and gender don't matter in such things - as much as I wish they didn't - the fact is they do.  I hope that as I move through both my professional and personal life that people will look past gender, past race - and see me.  A little ITIL imp :)

Happy one month anniversary to me!

Well, today marks the first month of my new job and how the weeks have flown by without my making many blog posts.  I am so busy both at work and home that I just don't know where the time goes (well I do, but I'm not going to bore you with it).

After the first two weeks were primarily spent identifiying and meeting stakeholders, the next two weeks were focused around collecting the information for the development of the Project Initiation Document that had to be in on Wednesday 8th October.  I was able to use much of the input from the one-to-one stakeholder meetings I had but we also held a project kick-off workshop and used this to get ideas from everyone together to address things like objectives, constraints, risks, benefits, deliverables, and assumptions.  This proved very worthwhile as it helped create that shared understanding about the project and was a great input into the PID.

I actually had to write two of them, one for the local council project and one for the wider programme across all councils.  The more I worked on the latter one the more I realised it was really a programme definition document according to OGC's 'Managing Successful Programmes'.  I recently bought the book although I've not finished reading it yet so I was making a lot of reference to it as I wrote this document.  Nothing like learning through doing is there? ;)

Now that the first milestone is out of the way and I've developed the project plan that we will be working to, it's time to start making things happen.  I guess this is when the REAL challenge begins...

Starting from scratch...

Well, this week marked the start of a new role for me.  I'd always assumed that my next role would be that of a Service Delivery Manager - yet I have moved out of the operational IT environment and taken a leap into the business change environment.  I'm now a project manager on the business side (albeit with an IT background).  These days there is a lot of talk about how IT folk, CIOs especially, need to understand the business units that they support; what better way to do that than to take the plunge into said area?  Inevitably there will be ups and downs to go with the new challenges.  It all makes for the perfect personal development opportunity - and one that will get my career where I want it to go.

So... week one.  My objectives were to get a better understanding of the project(s) that I would be working on, meeting key people (potential project team members and primary stakeholders), and an understanding of the new environment I'd be working in.

Monday - I go through the usual induction stuff and find that everything isn't quite as expected with my new room or IT setup.  On the upside these small issues provided me with opportunities to get well acquainted with facilities and IT sooner than I had planned to.  Everyone proved really helpful and focused on getting what I need to do the job.  A positive day on the whole.  The only negative thing was that, although intellectually I knew that it would be hard moving from IT to the business side, I hadn't reckoned on it being so damned frustrating to find myself a 'user' and all that means, i.e. subject to user IT policies and unable to do all I am used to doing!

Tuesday - Main achievement of the day, meeting and picking the brains of the Contact Centre Manager who will be a key stakeholder in the integration project.  Obtained a wealth of information in a short time which all contributed to my weekly goals.  Once I got home I was missing the people I used to work with and elements of my old job.  Had to remind myself why I made the move and gear myself up for the next working day.

Wednesday - Very busy yet rewarding day.  Introduced myself to the IT managers and met with every member of ICT who was present.  Coming from IT myself, I know that without their support this project will be going nowhere fast.  I also met a potential team member who specialises in process mapping.  A skillset that I have some, yet limited, experience with so it's great to have someone around who is very passionate about the subject.

Thursday - At short notice I managed to meet the project customer (senior user) for a one-to-one prior to our formal meeting next week.  Very informative and useful - yet another person with great energy and enthusiasm.  Either there are a lot of those in this organisation or I've just been very lucky in meeting the few that are thus far - time will tell.

Friday - The first project board meeting with me present.  My one deliverable to show for the week thus far is a draft project organisation chart identifying programme board, project board, project team members, stakeholders and other interested parties.  The fact that I had met a lot of them helped.  I spent the afternoon in the contact centre getting to grips with the various systems in use and how they are used in conjunction with one another.  All very positive thus far - I go home tired and happy.


Conclusion after week one: Initial objectives achieved.  Coming from an outside organisation I have no credibility here; I am starting from scratch.  Spending time meeting people, making an excellent first impression, and gathering information about people and the organisation are all key if I am to be successful in this role.  Being me, I intend to be ;)

You're fired...You're hired! - Prince 2 style...

The Imp has been on adventures in another country and is now back, refreshed, and looking forward to what the remainder of 2008 holds. How fast it seems to be going!

If you are one of the many who have seen Alan Sugar's 'The Apprenice' and you have an interest in project management, you may appreciate this post. I read an amusing white paper published by FGI ltd entitled: '"You're fired": What The Apprentice Project Managers could learn from PRINCE2™'

The author takes us through a review of the series highlighting some of the tasks and how things could have been handled had the Prince 2 methodology been applied (in a very pragmatic way I might add). It leads to a rather interesting conclusion over who should really have been hired and who should have been fired. I won't give it away - read it for yourself (note - their Prince 2 resources website requires registration).

Where next for transformational government?

I've been re-reading some information on Transformational Government as it's now two years since the original strategy was published back in November 2005. Amongst implementation and progress papers I found a really interesting one in the Work Foundation's 'Public Services & ICT' series entitled: 'Where next for transformational government?' by Alexandra Jones and Laura Williams. It's dated September 2006 but the content is still very relevant to where I work over a year on. After giving some background it details the challenges that we continue to face:

• Lack of link between project and organisation's key strategic priorities
  
• Lack of clear senior management (and ministerial) ownership and leadership
  
• Lack of effective stakeholder engagement
  
• Lack of skills and proven approach to project and risk management
  
  • Scope Creep
    
  • Unrealistic Timescales
    
  • Perfection tomorrow rather than compromise today
    
  • Not enough attention paid to risk profiles
  
  
• Lack of understanding of and contact with supply industry and senior levels
  
  • Avoid over-design of the procurement specification
    
  • Create genuine partnerships
    
  • Be realistic about risk transfer
    
  • More honesty from suppliers
  
  
• Evaluation of proposals driven by initial price rather than long-term value
  
  • Business benefits should be the real measure of success
    
  • Not just time and cost
  
  
• Too little attention to chunking project into manageable steps
  
  • More projects need rigorous piloting
    
  • Lack of Communication between policymakers and deliverers, and IT managers and senior managers
  
  
• Inadequate resources and skills to deliver the total delivery portfolio

And conversely, it also highlights what makes a successful project (nothing really new here):

• Clear and realistic business strategy with ICT as enabler
  
  • Keep it simple
    
    • Simplify transactions
      
    • Incentivise cheaper options
      
    • Different solutions for different services
      
    • Design services around customers
      
    • Do a pilot
      
    • Have a safety net
  
  
• Processes redesigned to be more effective
  
• Leaders engaged in project and visibility committed to success
  
• Change management strategy engaging staff
  
• Investment in capacity of staff
  
• Customer segmentation - Understanding different customer needs
  
• Good relationships with suppliers
  
• Risks identified and managed

The report finishes with 10 recommendations. I won't detail them here though, go and have a look for yourself. It's actually a really good report (unlike some I've read).

Do you see these challenges for you and your organisation (if you work in government anyway!)?

Crucial Conversations - buy it, read it, do it!

Given the publication date of 2002 I'm late to the fold on this one, but I found reference to 'Crucial Conversations: Tools for talking when stakes are high' whilst reading a report called 'Silence Fails: The Five Crucial Conversations for Flawless Execution' and thought it would be worth a read. It was.

Fundamentally the book teaches you how to:
1. Recognise a crucial conversation - "A discussion between two or more people where stakes are high, opinions vary, and emotions run strong." (Get Unstuck)
2. How to analyse what is happening (Start with the Heart, Learn to look)
3. What to do about it (Make it Safe, Master my Stories, STATE My Path, Explore Others' Paths, Move To Action)
This is then summarised as a visual 'dialogue model' at the end of the book (which makes much more sense if you've actually read the book first!).

The style of the authors is an easy going conversational one which makes for quick reading. However, it's one of those books that you absolutely have to absorb, practice, go back and re-read, practice, etc. There are also supplementary materials (videos, self-assessment questionnaires, group questions) available on the vitalsmarts website if you register.

Much of what they say resonates for me with that which Mark and Mike teaching over on the Manager Tools podcast series.

If, like me, sometimes you get in a mess in a crucial conversation - then get this book and practice what it preaches. I certainly will.

Silence Fails and Crucial Conversations

I recently came across a fascinating report called 'Silence Fails: The Five Crucial Conversations for Flawless Execution' . If you involved in projects at all, be it as a team member, a project sponsor, project manager or otherwise, I highly recommend that you register and download a copy of the report. To summarise those 5 crucial conversations:

Problem 1: AWOL Sponsors. 65% of project leaders work regularly with sponsors who fail to give the required support, leaving projects stranded and exposed.
Conversation: Project sponsors must communicate, providing leadership and political support.

Problem 2: Fact-free planning. 85% of project leaders are given parameters such as deliverables, budgets and timelines with no opportunity for input.
Conversation: Project leaders must be involved in the earliest stages of planning.

Problem 3: Skirting. 83% of project leaders say their effectiveness is undermined by powerful stakeholders and managers who attempt to skirt decision-making, planning and prioritization processes.
Conversation: Project managers have to stand up and maintain project discipline.

Problem 4: Concealing risk. 50% or more of project managers say team members regularly fail to honestly report project risks. As a result, the team loses opportunities to respond with revised goals, shifted resources or reorganized plans.
Conversation: Team members must be encouraged to speak up.

Problem 5: Team failures. 80% of project leaders are hobbled by direct reports who don't show up to meetings or fail to meet schedules or goals.
Conversation: Project leaders must insist on picking their teams, and they must confront inadequate performers.

I've ordered the book Crucial Conversations and will post my thoughts on it once I get around to reading it (doing a great job of adding to instead of reducing my reading pile right now!).

The 7 Sources Of Problems

I imagine that many of the ITIL readers out there are familiar with Dr ITIL. Some of you may even recall a series he wrote regarding the 7 sources of problems. I found it so useful that I diligently saved the articles to my hard disc for future reference; so when I found out about his first e-book 'The S7ven Sources of Problems: How to eliminate problems before they impact your business' I found myself wondering why I should pay for content that was already out there on the internet. That was until I read it!

The e-book goes far beyond the previous articles; a total of 66 pages. Diagrams are kept to a minimum, the majority of the book is content, content, content. It neatly distills not just what the 7 sources of problems are; but importantly HOW to mitigate and in some cases completely eliminate them. I find the writing style no-nonsense and conversational which makes for an easy read. Admittedly much of what he writes may be common sense to some people; but sometimes you need someone to remind you of what you already know; let alone point out the things you don't know.

In my view this should be mandatory reading for not just problem process owners everywhere, but anyone involved in project or change management, in fact include anyone supporting the IT environment and frustrated with the constant fire-fighting.

Start your journey of problem elimination by opening the door with the golden key (nudge, nudge, wink, wink!).

Into the frying pan - My first 'major' project - part 3

A couple of weeks into the project I was told by the board that I was to use PrInCE2 Lite methodology to manage the project - and they wanted a PID. PrInCE2? A PID? What's are they when they're at home? I made haste to the office of our resident qualified practitioner who thankfully took pity on my ignorance and walked me towards the light.

A few hours later I emerged with a seriously high-level overview of Prince 2 (which I now knew was yet another wonderful acronym - PRojects IN Controlled Environments) and some standard templates all prepared to write the PID (i.e. Project Initiation Document a.k.a. PDS - Project Definition Statement).

When I say seriously high level I mean that I came out knowing what SU, IP, DP, CS, MP, SB, CP, and PL stood for and a rough idea of what was needed in each - and I mean rough! For those of you not familiar with Prince 2 it is pretty hefty and not something that can be learnt just like that. I am not qualified and rather keen to attend a course so I can get my head around it all!

Anyhow, once I delved into the template for the Project Initiation Document I cringed. There were yet more terms I didn't know, and sections that needed answers that I didn't yet have.

Thankfully you need not scour the web for such definitions as I have 2 links to recommend that will make quite the difference. The first is the Glossary of Terms (9 page PDF for download). The second is not exclusively Prince 2 but a truly excellent resource - Wideman Comparative Glossary of Project Management Terms v3.1.

In the next part of this saga, I will talk about the stakeholders and how I got their input (and in some cases how I failed to do so!).

Into the frying pan - My first 'major' project - part 2

In part 1 I talked about how I got involved in the rather interesting world of Project Management. In part 2 (and those that follow) I'm going to talk about some of the highs and lows along the way, my learning points, etc. So, onward!

The first thing we did was assemble a project team. This was quite a strange affair as, looking back, I think I had very little to do with the make up of it; rather, it landed in my lap. The first thing that happened was the board appointed one of their group to be the project executive (sponsor). As it happened he was from one of the other council's in the partnership. We met one afternoon and had a really good chat about ourselves and backgrounds, what we were expected to do, the kind of deliverables we wanted from it, etc. We seemed to see eye-to-eye on things and were keen that it needed to be a managed as short sharp project.

Then came the rest of the team. As one would expect we involved a Help Desk operator from each council - except the one I was from. Having started at this council in the role and continuing to oversee it, it was considered I had the required knowledge. We did include a member of technical support from one of the other councils to represent that viewpoint but that is where the team stopped growing. Although we had opportunities to invite a representative from a separate partnership technical sub-group; in hindsight it would have been better if they were included as part of the project team itself. So, we've got 2 project team members from each council except the one I work for who had, well - me.

Our first project meeting felt quite exciting and there was a very positive vibe. None of us knew one another and there was a lot of work to do to become a team, but still, we were all curious about how this partnership would work and here we were, starting to actually work together. Once we got the introductions out of the way and some understanding of one another's viewpoints we delved straight into figuring out just what we were expected to deliver.

We figured that a good place to start would be defining our ideal help desk operation and an appraisal of the existing call logging tools in use at each council (Heat, Sunrise, and Touchpaper). This is where I found questionnaires quite helpful to both elicit the information and to compile and compare the results afterwards.

And with that I leave you this cartoon that I believe is rather appropriate to the position we found ourselves in... and something you want to avoid at all costs (Found on http://www.grin.com/en/fulltext/ine/23156.html ) !

Into the frying pan - My first 'major' project - part 1

A couple of years ago I was asked to look into consolidating the help desk operations of 3 councils that were looking to work in partnership to deliver ICT services. My role at the time was that of a system support officer with a primary responsibility for help desk and customer service. The local face of IT if you will. Initially I was quite excited at the opportunity and could envision a more professional help desk providing better services. Seeing as they had asked me, they saw this too, right? Perhaps I was naive, and if I am honest I do have a tendency to be when I am excited about something.

I started off by forming a working group formed from the help desk operators / supervisors at the other councils and having a relatively informal chat about what I had been asked to do, followed by a fact-finding mission to discover what I considered to be key things. These meetings went very well and those involved were very open (contrast this with how closed the management themselves were on certain issues, especially when it came to finance). I've compiled a mind map (requires Mind Manager viewer) to show the areas that my questions covered. I hope it will act as a useful kickstart for someone out there faced with the same task.

Once this initial task was complete, I sought to gain further guidance from those that had given me the task before writing my report as I wanted to be sure it would answer their questions. Ironically, they couldn't tell me what their questions were. If I were me back then, the alarm bells would have been going off and I would have said that they needed to all sit down and figure out exactly what they were hoping for. As I didn't know then what I know now... I didn't.

I wrote the report which raised far more questions than it answered, of that I have no doubt. However, it did give management enough information to make the decision to formally go ahead and consolidate the help desks of the 3 councils. Result!

I shouldn't have been surprised when I was asked to be project manager - but I was. With no formal project management training behind me or substantive project mangement experience I felt that it was too high profile for a first 'major' project. I actually recommended that they appoint someone else and that I act as Project Lead. Looking back I'm glad they ignored my recommendation! They agreed that they would support and train me to use the Prince 2 Lite project management methodology to deliver the project, so I agreed to do it. After all, it's not often these opportunities come my way. (Incidentally, the training never came; at least not until after we had finished the project! I got by through primarily by reading project management books and websites on my own time - I'll document which I would recommend in another post for you.)

So there we have it... how I got into the frying pan that is project management, and subsequently ITIL. Stay tuned for part 2!