In a 6 person project the project manager can handle the project admin himself. In a 60 person project the PM will need a project office to handle the admin for him:
Should the project office produce, own and update the project plan? No. This is a job for the team leaders as we shall see.
The project office provides admin support to the project manager, they do not manage the project for him.
In a large project there can be literally thousands of documents and versions of documents: without first
class version control the project would soon descend into chaos. Want to know how many issues have been open for
more than two weeks? Ask the project office. Or, if you want to get this information instantly on your laptop at
any time of the day or night, ask the project office to set it up for you. A good project office is vital
in a large project. Civilisation is underpinned by the competence of its administrators.
If the overall project manager of an IT project has little or no IT knowledge they will need someone from IT to pull
together the IT team, manage IT's activities and report their progress.
This role is very similar to that of the overall project manager, if less broad in its scope.
Some would argue that the project user manager role is the most important role on a software project, the most difficult to perform and the role least likely to be properly defined or assigned. A pretty deadly combination. Furthermore some methodologies don't properly include this role.
However big the project, there is only one project user manager. If it's time for a cup of coffee wander off and see if you can list, say, three specific responsibilities for this role. Glance at the organisation chart to see where the user PM sits in the hierarchy.
|
|
This is what the project user manager should do:
Represent all who will use the project's deliverables. Ensure that all users have a voice and their needs and views are considered by the project.
Find and commit business resources. It's all very well for the steering committee to make well-intentioned promises of boundless user people to work on the project. The project user manager has to (on behalf of the project manager) go out into the business highways and byways to prise out real, named, warm bodies to do all those things users need to do: define requirements, agree designs, user testing, etc.
Arbitrate amongst users. Users in Finance may want things done one way but users in Marketing think the requirement is quite different. The project user manager has to be empowered to resolve such disagreements so that a single view of the users' requirements can be given.
Sign off the requirements document. The project user manager signs off the requirements document which says to the sponsor: "your requirements have been fully defined and are complete and correct." And if they later prove not to be, the project user manager won't be getting much of a pay rise this year. Quite an accountability.
Sign off the User Functions Design document. At the end of the User Functions Design step, the user project manager signs off the UFD document: "Sponsor, the User Functions Design document is complete, correct, satisfies our business requirements and the system as designed is useable." And if it isn't... An awesome accountability.
Put yourself in that position: you are accountable for the correctness of the design for some huge new system that will eventually run your company's whole business. We are at the start of the User Functions Design step: we are building the plan for that UFD step. In two month's time, when the UFD document is finished, you must sign it off. Would you do nothing for the next two months, and when the document arrives on your desk shut your eyes and sign it then take it to the sponsor and say: "it's fine, you can sign this off, sponsor"? Don't think so.
As part of the planning of the design step you approach, let's say, the marketing manager and ask for one of his people to work full time for the next two months in the design team to ensure that the design meets the requirements Marketing have specified. But the marketing manager says although he'd like to help he cannot spare anyone for that. And you get the same brush off from every other business area you approach. What would you do (other than panic)? You would have to say to the project sponsor (directly or via the project manager): "Sorry, sponsor, I cannot perform that role. The role has no meaning unless it is me marshalling representatives from each business area and making them, and the people they represent, think through whether the design really does meet their needs and making them sign off on behalf of their domains. Only then could I sign off to warrant to you that the design really does meet your business needs."
The sponsor has just discovered he has a problem: he hasn't got adequate user involvement to ensure that the design will meet the business (i.e. his) requirements. If he (via the project manager) hadn't given someone this rather awesome accountability he might never have known - until it was too late.
In some methodologies this accountability is assigned to a member of the steering committee (project board) but that senior manager or Director might only devote a day or two a month to the project. We are talking here about a project user manager who works full time on the project to make sure the design is correct from the users' perspective. What we are suggesting is not at odds with these methodologies: it is, to be charitable, a way in which that steering committee member's responsibility may be delegated and meaningfully discharged. To be uncharitable it fills a fatal, gaping hole in some methodologies. Some methodologies' reluctance to assign such a significant responsibility to anyone below Director level may be borne out of a perception that it would be "unfair" to give such a responsibility to a more junior person. But the result can be in practice that nobody on the ground is truly accountable for the requirements and design being correct and - guess what - they won't be correct and the fun starts when the system goes live.
Authorise change. Having signed off the UFD document someone must authorise subsequent changes to it. As we will see in a later chapter the project user manager has a key role to play here.
Sell the project to the business. Explain to all affected parties what's coming and when. Set their expectations appropriately. On a big project this can be quite a big endeavour with road shows, executive briefings, demos and so on. But if, when the users get it, they all complain it's nothing like what they expected the project user manager has some explaining to do.
Manage acceptance. Acceptance Testing, if you insist. The project user manager signs off at the end of testing and says the system is fit to go live. If there is going to be a user acceptance testing step the project user manager might even project manage it.
Training and implementation. Listed last, but this starts in parallel with the IT Technical Design step and includes designing and building user training materials, developing the roll out plan and then near the end of the project executing the training and roll out plans. In really large projects, implementation, training and roll out, etc is such a large undertaking that it may well have its own dedicated (sub) project manager. Just another example of the infinite number of possible project organisation variations that the project manager must select from.
Now, if you're screaming at the page
a) surely the project manager should do all of the things we have ascribed to the project user manager, or
b) surely the team of super users, one from each user domain, should do all of those things
it's probably because your experience has been of a) much smaller project or b) much larger projects than we
are assuming for the purposes of illustration. (Though even on huge projects there should be one project user manager
managing all those super users.) We will consider much smaller and much larger projects in a moment.
In summary, the project user manager is responsible for ensuring the project will meet the needs of the business.
...next
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium
www.hraconsulting-ltd.co.uk
Home Sitemap Contact Us Project Management Articles Project Management Book