PROJECT Management explored

Yesterday I heard a well known TV cook saying on the radio that if you haven't already started planning for Christmas then you have missed the boat.

It got me thinking about projects and how they are all around us and how people use project management approaches/competencies every day without recognising they are.  While we as project managers may be able to step back and realise that pre-ordering the Turkey is risk mitigation the majority of the population who aren't trained PMs just see it as common sense because everyone will want one….and the ones available on Christmas eve never look good.  We all know some people who prepare well and breeze through Christmas seemingly effortlessly without any formal project management training or skills, or dare I say...documentation! So does that mean the Project Management industry is false? Are our methods, tools and competence frameworks all overinflated and self important?

Perhaps sometimes just a little....but rather we should think about the complexity of the project at hand and the number of people involved in delivering it.  Low complexity projects, with limited risks and no regulatory drivers can often be delivered with very low levels of documentation and methodology and by individuals without much/any formal training.  I always like to think about 'Project Management' (the whole methods, tools, competence thing) as a communications aid.  After all it is true that people deliver projects and if you have a lot of people working together they need an unambiguous way to communicate, to know what their part is in the machine.

So this brings me back I guess to context and scaling....as my thoughts so often do.  Work out which projects are 'simplest' and use 'fit for purpose project management' on these.  Thereby freeing serious resource/activity/oversight to be focussed on the complex, risky projects where more structured processes and capabilities are required to let the teams function correctly.

Finishing off then, I bet someone organising a serious banquet like the one Obama threw this week has a project plan, a risk log and uses the full range of 'Project Management' to ensure success, they would be mad not too!

So we have previously looked at the fantastic portable application capability of the new Community Edition 2.0, today we explore its multi lingual capability.  This feature allows you to change the interface language used on Community Edition by creating a language file that you can share with your colleagues or friends to help with their adoption of your chosen methodologies. 

What's more it couldn't be easier to do:

• You simply download the Community Edition Language file from the knowledge base, save a copy with a changed name to reflect your new language;
• Edit the words and phrases on the right of the divider to your langauge of choice;
• Now take your created file and place it in the language folder within your Community Edition install area (..\PROJECT in a box Community Edition 2\language);
• In Community Edition go to options -> language and select your langauge from the pick list, save the options form;
• Restart for you changes to take effect and you will see your chosen language in use.

This is a true community capability so you are free to share your language file with your colleagues and friends giving them easier access to our standard PRINCE2, DSDM Atern and other method templates.  Also if you send your language files into us () we will get them reviewed and provide them to other community Edition users with a name check for you!  This could be great if you are trying to promote the methodology in your country.

How many times have you started a project without all the information about what required available...or where the client thinks they have given you everything but you know (and they often don't recognise) the gaps?  I'm guessing at least once, and probably quite a few times if you really think about it.  I know I have.

If using PRINCE2 to try and manage a project like this it can be difficult to work through SU and IP as essentials may be missing to finalise the Project Product Description and PID and often many assumptions are made (and hopefully stated) to enable progress to be made.  As the project progresses and better understanding and visibility enable the requirements to be more clearly defined projects often find their tolerances stretched or lots of time spent in issue management/change control and exception management as the team work through the mountain of RFCs that may result.  The nature of PRINCE2 projects which have a significant up front planning bias (for the project and at the beginning of each stage) means changes require expensive (time=cost) revisits and sometimes work that has already been undertaken is no longer required.

DSDM Atern provides an excellent solution to this by changing the way we look at delivering a project.  With DSDM Atern the project uses a prioritised requirements list and the scope is flexed to match a fixed cost and end date.  Key to managing this list in a logical way is to have frequent activity periods called timeboxes which have a subset of the prioritised requirements which are planned and delivered and the process repeated.  Some timeboxes may be devoted to development/production and others to research/prototyping and sometimes these are mixed so the project moves forwards in lots of bit sized manageable steps.  This way less effort if spent upfront planning things which are expected to change.

DSDM Atern has its own language, techniques and controls used to manage the process much of which will be familiar to those with some Scrum experience.  Over the coming weeks we will be exploring some of these techniques and controls and also looking at how these can be used in a PRINCE2 context to help manage those tricky projects where you know change is going to be the only real constant.

If you want to get started now then you are in luck as both Community Edition and the commercial PROJECT in a box systems now all provide DSDM Atern as standard.  As you will expect we have licensed the material from it's owners so you can use it with peace of mind.  The DSDM Atern method also comes with a useful amount of official guidance so if you are not familiar with the method you can check as you explore.

Many customers come to us say they are looking for a system as they want to, or have been told to  implement PRINCE2.  With PROJECT in a box being the leading PRINCE2 software solution and providing authentic PRINCE2 process and templates under licence this seems an obvious and cost effective way to go.  We also provide as standard, pre scaled PRINCE2 methods so customers can give a lighter PRINCE2 treatment to a small, low risk project than to a large complex and risky project.

The comfort this approach gives customers often means that even though we advise against they implement straight out of the box using the standard methods as provided.  Whilst this isn't a critical issue in itself it will mean  more work for each PM during start up to personalise the documents to their project and the potential loss of other important benefits.

What we strongly encourage, as does the PRINCE2 manual,  is a good degree of personalisation and by building this into the standard method templates at launch you can make sure this work is undertaken once and used on every project.  The work generally falls into three areas:

• Branding - as simple as putting your logo on every template or a complete styling of the browser interface and branding enhancement of the navigation diagrams.  This is straightforward to do and has a significant effect on the end users who now start to see the tool and methodology as theirs rather than an external imposition.
• Content - most organisations already have some templates which are well used already  such as business cases or mandates and these can be used to replace the standard ones provided.  Unless of course one of your reasons to implement is to replace documentation which is perceived to be insufficient, in which case you might like to take the style of the previous templates but add to the recommended fields.  Content needn't just mean files, you can also template hyperlinks and windows short cuts to important resources inside and outside the organisation i.e. links to policy documents on your intranet.
• Data collection - if you are planning on using PROJECT in a box to do your project, programme or portfolio reporting then you can alter the collection spreadsheets and forms provided to the projects so that the correct information is collected and aggregated for reporting.

This is all work that you can do yourselves to keep implementation costs down but also to ensure you have 'ownership' of your methods going forwards so you can keep evolving them as the nature of projects or your project environment changes.

Some customers take this much further and create domain specific project method templates such as having a method for an R&D project, a method for a production project and a method for a marketing launch.  If your organisation has some project consistency in domain areas like this and each type of project uses lots of specialist documents which are not used by other project types then this can be a great way of supporting the project teams with what they need to deliver in their particular environment.  Often we see these moves as a second step of evolution once users have been through several project cycles and find that they are often personalising their projects in the same way.

These sort of changes offer many benefits to the project teams, Project Managers and the organisation, to name but a few:

1. Time saving for the project manager and teams personalising a project from template
2. Better buy in from teams who feel less imposed upon
3. Engagement from the project managers and administrators who are empowered to keep the approach relevant because they can.....(if just following the standard PRINCE2, say from a book, which they can't change there is a tendency to say 'yes we know the language is clumsy' or 'that process doesn't work for us' but it can't be changed.  Instead actively engaging in post project reviews and feeding back user requests into methodology revisions and enhancements which they can control)

So in short, make your methodology feel at home and it will work better for you, like wearing a collection or tailored clothes as opposed to one single suit from a rack.  After all if you were going for a swim you wouldn’t choose to wear your suit would you?

Practicing what it preaches, OGC, the owner of the swirl methods set (PRINCE2, MSP, MoR, ITIL, P3O and the Gateway Review etc) periodically publishes lessons learned from projects and programmes it is involved with.

In September it published lessons learned on the SRO (Senior Responsible Owner) Role in Major Government Programmes and as you can imagine this made very interesting reading.  This was based on a review undertaken following an analysis of programme lessons learnt and Gateway Review feedback. It summarised that the SRO role could be made to work more effectively by addressing the following:

• Better understanding of the role
• Selection of the right people to act as SROs
• Giving SROs real accountability and business authority to resolve issues
• Ensuring SROs have relevant delivery skills and experience, including commercial awareness
• SROs dedicating sufficient time to the role
• Improved continuity of the role through the project life-cycle
• Improved tools, guidance and development opportunities for SROs
• Provision of adequate supporting resources

It goes on to say that these recommendations will be promoted and worked back into the guidance, including the MSP revision which is getting underway shortly.

Irrespective of the name SRO (mainly used in UK government) which most of us would more widely recognise as a Sponsor, if the person ultimately responsible for a project doesn't understand their role, grants insufficient time to it and lacks the skills, experience and support to operate effectively, then however effective the project team, the project will be at risk..

Such a frank and honest assessment of the situation and subsequent attempt to start addressing it deserves praise and we should each consider whether as PM we would be prepared to tell our Sponsor they were a risk to the project?  Difficult? definitely, but usually worth the downsides.

Finally I leave you with a quote from the summary paper " over half the Senior Responsible Owners (SROs) are in their first SRO role, and nearly half spend less than 20% of their time on such duties.  Lack of relative experience, combined with a regular turnover of post-holders, adds unnecessary risk to the management of IT-enabled change".