As part of a course on community development and regeneration there is a module on project management in a community context. But, I'm not getting it much. I think I might know why but want to see if I'm right.
When I try to make sense of pm, I first think this way: I see there needs to be a problem identified, then a solution to it, then implementation of the solution. I think that is generally right - what solves the problem is a solution. And I think on this score, we are talking about research to find out the problem, then doing a problem tree and these two tasks going a long way to creating what is at the heart of what actually sorts the problem (at the heart: identified key objectives (objectives tree)).
Yet, my suspicion is that project management, in the main, has much more to do with things that don't actually directly bear on the problem solution. Things like stakeholder analysis, SWOT, feasibility study etc. It's like 10% of the work is actually working on the solution itself, but 90% making it all come about.
Comments appreciated. Thanks.
Bringing Clarity to Project Management
Richard,
I don't think it's a 10% and 90% split, but 100% of Project Management for the life of the Project, and 100% of of Specialist delivery to deliver the products of the Project, as required.
I hope this simplified process summary is found to be relevant and useful to you:
The role of the Project Manager (PM) is to understand, document, report on and manage all aspects of the Project from the Business Case through to Project Close down. The ACTUAL WORK (e.g. hands-on technical etc) is undertaken by technical individuals or teams of specialists. It is NOT the job of the PM to become a Subject Matter Expert (SME) in all fields of each project, and it is NOT the job of the PM to DO this kind of specialist work either (even if he can, he really shouldn't!!).
The word 'Stakeholder' simply refers to *anyone* who has an interest in the Project, however minor.
The Business Case defines the reason for doing the work and the expected benefits etc. and it is THE driver for undertaking the project. If at any time the Business benefit of doing the project ceases to exist, then the point of actually doing the project automatically ceases to exist also.
If the PM is lucky, from the start he will get a very well written brief on everything to do with the Project, whose involved and confirmation that the Funding etc is already approved. Most of the time this is NOT the case, and the PM has to get this sorted himself. Do bear in mind that whilst the PM works ultimately to deliver the Project for the guy with the purse strings, most of the time there will be an Exec or Senior figure above the PM who is ultimately accountable to the business for the Project delivery. (The PM works to deliver the Project on behalf of the Exec).
Whilst the likes of Prince2 bang on about 8 Components and the rest of their multi-part Project methodology, a Project can in fact be simply viewed as this:
1) A Controlled Start
2) A Controlled Middle
3) A Controlled End
To be more specific:
1) Ensure a Business Case exists and Finance is approved. Scope the work, list the risks and issues (tracking them to resolution etc), list assumptions made and ensure all Stakeholders are identified. Get as many SENIOR Stakeholders involved and made responsible/accountable as possible (this is invaluable when you need some muscle to get things moved-on during the project!). Get END USERS involved ASAP and KEEP THEM INVOLVED throughout!
Share each step of the Solution Planned and with all Key Stakeholders as it will give them a chance to become fully aware of what will be delivered, how it will be delivered, and by when. It also gives them a chance to change the plan if needs be. DO get the Key Stakeholders to SIGN the plan as *good* before ANY work starts. DO NOT allow yourself to be rushed into getting the implementation/delivery 'work' started before the Planned Approach has been signed off by the Key Stakeholders - or it'll come back to slow you bite you later (count on it!). Also, DO NOT allow the Project to deviate from the plan because Manager X decides he would be better off with 10 wheels on his wagon instead of the 5 everyone has agreed will be delivered. ANY CHANGES to the planned work should be Changed Managed in, as they always carry extra Time, Cost and Quality implications. Once the addition of Changes has been agreed and the funds and extra time have been made available, the Project can be re-planned and kicked-off again at the next convenient point. A Lessons Learned Log should all be kept to record all good and bad lessons that you can learn for your next Project.
[Ok, this is now turning into a book, so I'll keep the rest brief!]
2) The Controlled Middle is about the production of the Project deliverables, quality assessment, re-work if necessary. Local Testing, User Acceptance Testing, and Pilot Implementations. It is the Iterative part of the Project which generates the proof that the End Users deliverable products can be created to the planned spec, within the agreed time and to the agreed quality.
3) The Controlled End is about the Key Stakeholders agreeing that all Tests and Pilot implementations went well and the process for delivery can be signed off as good. It is the time when handover into Support is finalised and the ACTUAL delivery/implementations can be carried out prior to Support taking over.
The last part of the Project is about getting the nod to Close the Project, disband the teams, close the Accounts etc. and have a 'wash-up' meeting to discuss what went well or badly. It's also a good time to review and complete any comments in your Lessons Learned log.
I feel like I've written more than enough here and that my comments might even have strayed away from the point of your original comments - but I do hope you found at least some of this useful.
Kind Regards
I don't think it's a 10% and 90% split, but 100% of Project Management for the life of the Project, and 100% of of Specialist delivery to deliver the products of the Project, as required.
I hope this simplified process summary is found to be relevant and useful to you:
The role of the Project Manager (PM) is to understand, document, report on and manage all aspects of the Project from the Business Case through to Project Close down. The ACTUAL WORK (e.g. hands-on technical etc) is undertaken by technical individuals or teams of specialists. It is NOT the job of the PM to become a Subject Matter Expert (SME) in all fields of each project, and it is NOT the job of the PM to DO this kind of specialist work either (even if he can, he really shouldn't!!).
The word 'Stakeholder' simply refers to *anyone* who has an interest in the Project, however minor.
The Business Case defines the reason for doing the work and the expected benefits etc. and it is THE driver for undertaking the project. If at any time the Business benefit of doing the project ceases to exist, then the point of actually doing the project automatically ceases to exist also.
If the PM is lucky, from the start he will get a very well written brief on everything to do with the Project, whose involved and confirmation that the Funding etc is already approved. Most of the time this is NOT the case, and the PM has to get this sorted himself. Do bear in mind that whilst the PM works ultimately to deliver the Project for the guy with the purse strings, most of the time there will be an Exec or Senior figure above the PM who is ultimately accountable to the business for the Project delivery. (The PM works to deliver the Project on behalf of the Exec).
Whilst the likes of Prince2 bang on about 8 Components and the rest of their multi-part Project methodology, a Project can in fact be simply viewed as this:
1) A Controlled Start
2) A Controlled Middle
3) A Controlled End
To be more specific:
1) Ensure a Business Case exists and Finance is approved. Scope the work, list the risks and issues (tracking them to resolution etc), list assumptions made and ensure all Stakeholders are identified. Get as many SENIOR Stakeholders involved and made responsible/accountable as possible (this is invaluable when you need some muscle to get things moved-on during the project!). Get END USERS involved ASAP and KEEP THEM INVOLVED throughout!
Share each step of the Solution Planned and with all Key Stakeholders as it will give them a chance to become fully aware of what will be delivered, how it will be delivered, and by when. It also gives them a chance to change the plan if needs be. DO get the Key Stakeholders to SIGN the plan as *good* before ANY work starts. DO NOT allow yourself to be rushed into getting the implementation/delivery 'work' started before the Planned Approach has been signed off by the Key Stakeholders - or it'll come back to slow you bite you later (count on it!). Also, DO NOT allow the Project to deviate from the plan because Manager X decides he would be better off with 10 wheels on his wagon instead of the 5 everyone has agreed will be delivered. ANY CHANGES to the planned work should be Changed Managed in, as they always carry extra Time, Cost and Quality implications. Once the addition of Changes has been agreed and the funds and extra time have been made available, the Project can be re-planned and kicked-off again at the next convenient point. A Lessons Learned Log should all be kept to record all good and bad lessons that you can learn for your next Project.
[Ok, this is now turning into a book, so I'll keep the rest brief!]
2) The Controlled Middle is about the production of the Project deliverables, quality assessment, re-work if necessary. Local Testing, User Acceptance Testing, and Pilot Implementations. It is the Iterative part of the Project which generates the proof that the End Users deliverable products can be created to the planned spec, within the agreed time and to the agreed quality.
3) The Controlled End is about the Key Stakeholders agreeing that all Tests and Pilot implementations went well and the process for delivery can be signed off as good. It is the time when handover into Support is finalised and the ACTUAL delivery/implementations can be carried out prior to Support taking over.
The last part of the Project is about getting the nod to Close the Project, disband the teams, close the Accounts etc. and have a 'wash-up' meeting to discuss what went well or badly. It's also a good time to review and complete any comments in your Lessons Learned log.
I feel like I've written more than enough here and that my comments might even have strayed away from the point of your original comments - but I do hope you found at least some of this useful.
Kind Regards