The Third of 8 Habits of Highly Successful Project Managers: Organize for Success – Part 2!
By Richard Morreale
So far in this series, The 8 Habits of Very Successful Project Managers, we have covered the first Habit – Know Your Outcome, the second Habit – Plan the Achievement and Part 1 of the third Habit – Organize for Success. This article will cover Part 2 of Organize for Success. This includes working with a Project Support Office, working with the Users and working with an Independent Test Function.
The Project Support Office
The Project Support Office (PSO) is organized and implemented to do just what it says – support the project. That is done by providing support to the Project Manager, the Project Team and the Project Board. So what is the Project Support Office and how does it work?
The PSO is a central pool of resources with specific support skills. Although you can make it responsible for whatever you choose, it is usually responsible for supporting Project Planning, Reporting and Control, Configuration Management, Documentation Management, Risk and Issue Management, and Quality Review Management.
In terms of support to Project Planning, Reporting and Control, the PSO assists the Project Manager and the team in the preparation of the detailed Project Plan, in gathering the data so that management can monitor achievement to the Plan and in the preparation of the various Achievement Reports required throughout the Project and at all levels of the Project. Make no mistake about it, even though the PSO assists in the preparation of the Plan, the Project Manager and the Project Team ‘own’ it.
In supporting Configuration Management on the Project, the PSO is usually responsible for maintaining the records associated with each of the Configuration Items and the Configuration Item Baselines along with administering the Change Control Process and maintaining a database associated with Change Control. The Configuration Item records include identification of the latest version of the Baseline documentation while the Change Control Database includes the status of every Change Proposed to the various baselines.
In the Documentation Management area, the PSO is responsible for the implementation and operation of a Project Library system. The Project Library becomes the repository for all Project documentation including the approved Baseline documentation including approved changes.
In terms of support in the Risk and Issue Management area, the PSO is responsible for implementing and operating the Risk and Issue Management Process. This includes setting up Risk and Issues Workshops, maintaining the Risks and Issues database, gathering achievement information concerning the mitigation actions and reporting on achievement in the various Project Reports and to the various levels of management.
The PSO is responsible for supporting the Quality Review Process including the acceptance items requiring review and distribution to applicable members of the Project Team, gathering of review comments to be presented at a Quality Review meeting, facilitating the Review Meeting and maintaining the records required to support the Process.
Working with the Users
I am a firm believer that the Users must be a part of the Project Organization. I’m making a distinction here between the Project Sponsor/Business representative on the Project and the actual user of the system being developed. I believe that the person at the ‘coal face’ will have a much better handle, from an operational standpoint, than the Project Sponsor. The Project Sponsor or Business Representative will have a much better handle on other areas and therefore should also be represented on the the Project. The actual user should be represented on the Project Board, be active in the details of development, be part of testing and should share the responsibility for delivering benefits with the Project Sponsor or Business Representative.
The user activities should be included in the Project Plan and monitored the same as everyone else on the Project. In fact, anyone performing activities that affect the success of the Project should be included in the Project Plan.
One of the most important parts of the Project organization is an Independent Test Team. An Independent Test Team is set up to test what the final delivered system is supposed to do, in accordance with the agreed requirements, and not necessarily what the system does. Hopefully both of those things will be the same but I have found that in too many cases they aren’t.
On an IT project, Independent Testing takes place after development testing and when development can no longer access the system. It should take place before user testing begins and should be resourced strictly by testers. The team should not include anyone who worked on the development of the system. The Requirements Documentation should be the basis for the preparation of the Independent Test Scripts and any errors should be corrected by the development team after a structured handover of the system back to development. Once the error has been corrected the system should be handed back to Independent Testing using a tight structured handover process.
So, in summary, the third Habit tells you to organize to the plan, establish a Project Board, use the 3 Amigos for greater success, establish and operate a Project Support Office, include the users in the project and establish an Independent Test Group.
Richard is a project manager, professional speaker, author and consultant specializing in Project Management, Leadership, Achievement and Customer Service.