Project Management as a Profession?

There has been a lot of discussion recently around whether Project Management should be seen as a profession, sitting alongside accountants, engineers, architects, doctors and so on. My initial thoughts are Yes!, of course we should be recognised and acknowledged for the professional approach we offer, covering the myriad of disciplines and expertise that any good project manager must possess. But I have three major concerns about this:

• There is no single governing or regulatory body in the UK
• The term "Project Manager" is over used to describe a wide variety of roles
• The scope of Project Management doesn't fit well into defined work categories

I'll expand on these three thoughts in future posts, but feel free to comment robbie@grayfulton.com

MP's Expenses

I’m not going to get into the whole argument about this topic… but I just hope they appoint a decent project manager to re-engineer the process and regulations. They won’t of course, and we’ll end up with an even more convoluted process which costs more to run than the outrageous expense claims themselves. I’m going to write to the PM and offer my services, but in the meantime I must go and clean my moat…..

Role Definition

Too many projects start off with a list of roles which have either been copied from an earlier project (and not updated) or are too loose in description to mean anything. They’ll be hidden will inside the start-up documentation and are unlikely to be given anything more than a cursory glance at sign-off, and certainly won’t be referred to again in the course of the project. So why bother? Because clear definition of roles within a project is as important as defining the requirements – especially in a small company where everyone has other roles to perform outside the project. As the Project Manager you need to know who will do what, and what they will be responsible for. Do you need everyone to sign off each piece of work or will you have the responsibility for this? Clarity around roles will save a lot of time and confusion later on – sit down with the project team including the sponsor, suppliers and end users to talk through what each group will (and won’t!) do so that everyone knows what everyone else will be doing – this may cause issues and arguments but persevere with it – better to have these out at the start of the process than have to deal with them when you’re in full swing!

Lessons Learned

Every single project management course will sing the praises of a Lessons Learned or Evaluation report to be carried out at the end of a project – there are loads of reasons why they benefit future projects and add to the project team’s learning. So why are they so rarely carried out? Lack of time? Lack of willingness to admit any mistakes?
Firstly, make time – add it in to your project plan and ensure all the stakeholders are included in the input so that good work can be praised and not-so-good work can be analysed and refined. And secondly, it’s not a blame game – giving praise will automatically allow people to objectively review their own work and agree where improvements can be made. It takes a strong project manager to admit to their own mistakes but it will also encourage and engender a more open and honest project environment.

Use Change Control to your advantage

I’m a great believer in minimising documentation within a project – anyone who slavishly follows the process and form filling without always understanding the benefits or appropriateness will never learn the fluid approach required to become a really good project manager. But there is one area where you can use pedantry to your advantage – Change Control. The dictionary definition of “millisecond” should be redefined to the time between someone suggesting any change to your (carefully planned) project, and the Change Control forms being whipped out. Of course, there will always be necessary change, and a robust process of analysis and acceptance is a good and necessary control, but nothing can stop whimsical and spurious add-ons in their tracks like a wad of Change Control papers. Firstly, ensure your process is clearly defined for impact and benefit assessment, then front load the process with a detailed input form, completed by the proposer (never fill these in yourself!) Then sit back and wait for the stream to dry up to a trickle.

Growing Your Small Business with Project Management

I found this article by Michelle LaBrosse which identifies a number of reasons why good project management skills can help a small business, focusing on the advantages of having a simple defined process, the reduction in costs and how to recognise and define projects. It’s a high level view but includes some interesting points to think about – and if you need any assistance with implementing any of the suggestions, give us a call at Gray Fulton.

Click here to see the article

WSMBC

The Westminster Small & Minority Business Council (WSMBC) aims to promote small business growth within the Westminster area, encouraging large businesses to provide training and support. It's free to join and there's a recuitment drive on at the moment - a prize of a bottle of "bubbly" for any referrals. Depending on whether it's a bubbly drink or a bubbly bath, I'll share it with you if you join.

New Training Module - Roles

A new training module for "Roles in a Project" has been added to Gray Fulton's training programme, explaining the need for a good definition of roles at the outset, so that all stakeholders understand their responsibilities - and each other's! Gone are the days of generic Role Definitions, copied from one set of project documentation to another - each new project should have a refresh of the roles, escalation routes and responsibilities. This new module is directed at everyone involved in the project, from sponsor to end user, supplier to internal provider. Contact us for more information training@grayfulton.com

Top Reasons for Project Failure

Not wanting to start on a negative note, but the top reasons for projects failing are:

• Business case not clear
• Objectives not fully defined
• Poor communication at the start and throughout
• Roles are not well defined... or fully understood!
• Estimations of time and effort are poor
• Planning and scheduling is not properly carried out
• Minimal control or measurement in place

Note how most of these relate to the initiation stage of the project - get the start up correct and the rest is easy!