The other week, whilst running a project management course, I was discussing what to do at the beginning of a project. During the discussion it became clear that some of the attendee’s ideas about when their project management role should start were quite different to mine. Their projects were mainly about building internet products such as new websites, new mobile applications or social media systems. They tended to get involved when it was time to build these products mainly managing the delivery teams, tracking progress and co-ordinating activities. Prior to their involvement senior directors in their company had already agreed with the client the details of the project such as what was to be built, how long it would take and how much it would cost. Well I say “agreed” – in some cases the scope and definition of the project was all rather ambiguous.
Of course there are numerous problems with agreeing the project’s practical details without any representation from those who will manage the project and deliver the products. In the case of the company I was training, the senior directors were coming up with guesstimates without investigating what was involved. These sorts of estimates inevitably have a high degree of inaccuracy.
I’ve talked on this blog before about the importance of starting a project correctly. Starting a Project Successfully Using PRINCE2. I think the time in the project before any of the products or services are built is the most important part. This is when the stakeholders are identified, and the details of the project’s definition and scope are agreed. The trouble is, like the company I was training, many organizations don’t see this time as part of the project itself and so don’t get the project manager involved.
I had a similar experience many years ago when I worked for a company that sold internet hosting services to large corporate clients. I managed a delivery team who set up the hardware and software infrastructure for the customer’s websites. When I first worked there, the sales people were used to getting away with selling very ill-defined projects and agreeing to unrealistic time scales with the new clients. The projects were then handed over to us. Of course it usually became clear that we wouldn’t be able to deliver the services to the schedules that had been agreed.
After a few spectacular failures we agreed a new process with the sales team. When they believed a prospective client was about to sign, they would ask us to meet them. We would then discuss with the potential client their high level requirements and prepare them for the fact that during the first week or so after they had signed up, we would need to scope out the project in more detail and set up a project team. Only after that would we be in a position to build anything. This process worked much better for all concerned. The potential clients could see we were more professional and were more likely to order the services and my team started delivering the better-defined project within the more realistic timescales.
So if you’re being given prior defined projects to manage, make sure you change this situation. Project management starts before you start managing the people delivering the products. The first tasks for a project manager should be about identifying stakeholders, working with them to agree the project’s definition and setting up a project team. The first deliverable for any project manager shouldn’t be a proper product (whatever that means within the context of your profession – part of a website, a design document, part of a building etc) but some sort of project definition document agreed by all the stakeholders. Only then is it time to start delivering real products.Permalink
Trackback URL for this post: http://www.orgtopia.com/2012/02/09/when-should-you-start-project-managing/trackback/