Congratulations! Due to the recent [acquisition / divestiture, market expansion / contraction, organizational realignments, other] you have been identified as a Critical Resource for this particular bit of business process change. And, to help us implement these changes, you have been named the Project Manager for this effort.
So now you are a Project Manager (PM, for short); what does that mean?
You may be vaguely aware that people get certifications for this sort of thing, or that Microsoft sells some Fairly Expensive Yet Sophisticated Software that helps create Can’t charts (or something like that).
You may also have this slowly growing sense of unease, as it becomes apparent that Project work is something that many folks don’t like to do – because being part of a Project Team represents an interruption to their already fully scheduled lives, with Tasks that will [by definition] someday End (… and where will that leave me?)
Every day, people in Operational areas of their companies get appointed to be “project lead” or project manager, but have had little training in formal Project Management. More often than not, however, the Project in question is of reasonable size (maybe 2-3 months in duration, with < 10 people on the team, and goals and objectives that are achievable “with stretch” (’cause if it was a no-brainer, we wouldn’t need to name you Project Manager, n’est-ce pas?). So relax for a bit, and let’s go through a little “crash course” in some of the basics of Project Management.
You may note, by the way, that much of PM may seem like simple ideas and common sense; this is true, and that’s a good thing to note – you’re calming down already.
Over time, you will learn that these simple ideas can be decomposed in many intricate bits; I wasn’t kidding about all that Certification stuff – as projects add people, systems, time and budget constraints, and shifting requirements, and you will understand why people talk about training and skills and battle scars …
Sorry, didn’t mean to lapse into that same old line of intimidating line of thinking … let’s just start with the basics.
What are we working on, and why are we working on it?
The new PM can be surprisingly effective with some fairly basic bits of information – clarity and reasonable precision go a long way when guiding a new team through a set of tasks that they aren’t used to doing every single day.
- Clearly state the objectives of the project – what are we trying to accomplish?
- What are the specific requirements? What are we building / implementing to deliver the objectives?
- Are there a specific set of features, functions, documents, new skills, new services, process addition/changes, etc. that need to be delivered?
- Any expectation of quality? Can this be slap-dashed together or must it meet the building code?
- Any time constraints? Is there any sort of must-have-by date, or can it slip a little bit (to get more features or better quality?
Note that Objectives are different than Requirements. I am trying to “deliver better customer service by delivering more accurate information on the invoice” (my objective). I will do that by “adding information to the customer orders, and printing it on the hard-copy invoices” (my requirements).
How are we going to get this done?
This is the most important, yet most often overlooked bit of PM work – you need to lay out the steps that need to get done, and who will do the work. Be careful – this is where many newly minted PMs get lost in the minutiae or intimidated by the details and intricacies – and folks often make mistakes in two different directions …
- Too much detail – bad, because the PM overhead becomes daunting, or the project work suffers from analysis paralysis and never gets started
- Too little detail – bad, because team members don’t fully understand dependencies, skip over key requirements, or underestimate work time
Keep it simple to start – you don’t need any fancy software or tools – a simple notepad will do. Just lay out the tasks required to get the work done, in sufficient detail such that you can reasonably gauge the total time required, and see where each of the major requirements will get covered.
You will also want to identify resources – people – who will do the actual work. Don’t talk in terms of “roles” or any fancy euphemisms – put actual names against each and every task. In addition, you’ll need to estimate how much time it will take to get each tasks done – you’ll have to add it all up, to check that it can all get done by any date you may have targeted for completion (ok, so maybe a spreadsheet would be a better tool than a simple notepad …)
Should we be working on this at all?
After laying out the tasks, you may find yourself going back to the total costs and/or the original estimated schedule with updates – and don’t be surprised if the time and costs increase, most people seem to estimate projects optimistically in the early stages. However, as your understanding of the total cost to deliver these requirements improves, it’s always fair to go back and validate if you should be working on this project in the first place – does it still make sense to go after the stated benefits if I know it will cost this much now?
The Most Important Thing
- Keep participants and sponsors aware of status – progress updates, major issues, coming milestones, etc.
- Track “planned work” (tasks) and “unplanned work” (issues)
- Capture knowledge – about new processes, assumptions, technical details, etc.
Remember, Rule Number One for project managers is Manage Expectations; most executives will tell you that they can handle disappointments when given enough lead time, but last-minute surprises are Bad, but magnified to Horrible with the lens of No Lead time To react.
A Nice Start – Now What?
Yes, you are right, there is much more detail to drill into on the Art and Science of Project Management. But let’s not forget that projects have been going on at your company for years – let’s not reinvent any wheels here …
- Does your organization have any standards or precedents in the functional area that you are working in?
- Is there a formal / informal, or traditional project methodology?
- Are there any existing communication requirements / expectations / traditions?
- Any available collaboration spaces, like SharePoint?
- Any available tools – for PM, for Training, for Knowedge Capture?
- Any available templates – for standardization, but also for short-cutting your work?
And remember, everyone else is happy they didn’t get picked to be Project Manager, so you don’t have to worry about competition …