I am working in an IT group on a phased, medium sized project. Management wanted us to score some quick wins by getting a base version of the software up and running along with some pilot projects.
Management was burned a few years ago by a senior manager who exercised terrifying levels of project bureaucracy where people had to spend most of their "project:" time updating their project plan and not in executing on them. There were other atrocities, but you could say that the operational IT groups (systems development, etc.) got burned out on PM.
Fast forward to, er now ...
On this project the steps seem out of order and I am trying to figure out how to get control of the project. We have not had a kickoff meeting yet. A manager thought it would be better to jump in and get the Dev and QA systems built as we planned things like governance and learned the system. Since it will take time to complete a governance plan AND get up to speed on the software it seems to me that our project is proceeding in fits and starts.
The project plan is in draft form,
I want to get this straightened out. With systems being built, not a complete project plan, and items with high impact like governance plans still being worked on, what are some initial steps that I can try to use to get this project manageable?
Thanks in Advance!
Saving Changes...
Sort By:
Loselo SegweSupply Chain Management Practitioner| Mahube - A - Naka TradingMafikeng, North West, South Africa
I think the most logical approach would be to finalize the Project Initiation Document that will guide all project activities and focus your efforts on what is defined in the project scope statement.
Moving forward and backwards would most likely result in other crucial project activities falling of the table and allowing none core project activities to assume priority. Saving Changes...
Some people will disagree with me, but sometimes it is necessary to start on work immediately, even before the plan and direction is key. Of course, if there is not a true crisis, I would STRONGLY recommend taking the time to plan, before you start to build. You might wind up building something you do not really need.
When I have been in this situation, where people were starting work without governance, plans, and other support, I used one of two techniques:
1. Progressive, simple planning and control
2. A call for stop-work, to make time to create plans and control
If you want to take the progressive track, then set a time in the future (perhaps two weeks from now). Start gathering information about what you will need to do from that point forward, to meet your project goals. Make sure you create plans, schedules, and assignments for the immediate work needed, doing the high-priority stuff first. You will need a high-level list of objectives (a project charter), but you will probably not have time to complete a full schedule, risk assessment and so on.
Then, when you actually get to the point that you have set the "start date" for the project plan, you can start to use the plan to control people's real work. You can continue to develop the plan, staying ahead of the actual work people are doing.
The reason I do this progressively, and the reason that I pick a future date to start the plan, is to avoid playing constant catch-up. If you try to track work starting TODAY, then you are always behind, and spend forever catching up.
If the project is really falling apart, if it is really complex, or if you simply cannot afford the risk of proceeding without a plan, then call for a stop to all project work. Get the teams in a room, and get them started creating the plan. You need either a lot of courage or great executive support to do this, but sometimes it is the best course.
You mention a "governance plan" that is being drafted. I would recommend starting with a one-page list of operating principles. Things like "do what is on the plan; don't do anything that is not on the plan", "No surprises; tell the PM about a problem as soon as you find out." You do not need a long, complex governance document. A good project plan should tell people what to do and when to do it. If the project manager can tell people, "Do the work, do it well," then you might have all the governance you need.
My worry is that the governance plan is still a "draft" because no one is sure who is in charge. If the PM is not assigned, or if the authority of the PM is not clear, then make sure you tackle that issue first. "Governance" can get very complicated, but authority and accountability should be very simple and very clear. Saving Changes...
Richard HowProgramme Management Consultant| How Associates LtdHarthill, South Yorkshire, United Kingdom
This is such a common problem. Business leaders believe that a project hasnt started until people are coding something. Its a bit like saying you havent started to build the house until the outside walls are going up.
With a house everyone knows that if you dont start with the foundations it will fail building control or fall down, or maybe both. Getting a basic plan built is the foundation of your project. If people are saying there is stuff they can be doing now and management agree that these tasks can happen then at least get all of that into your plan. A simple half day meeting with the project team should allow you to knock together an outline plan of the stuff you know you can get on with, best guesses at the stuff you dont know yet and a set of tasks that allow you to clarify the unkowns. This will give you a project plan that everyone can work to and be measured against and give you the chance to clrify the detailed plan. Everyone getting on with their own thing will only lead to one place.
As a PM you have to take control of the project and no one should do work that isnt on the plan, that doesnt mean that the plan has to be totally complete before you start the first task. Saving Changes...
I think it wil be important for you to take control of the project. This doesn't have to be heavy handed, but do something that says "this is what we're going to do." I like the suggestion of a project scoping or initiation document that people are requested to sign. Below is a TOC of a scoping document I did recently. The intended audience was the director of the business owner who is frequently late on his deliverables and changes his mind long after agreements have been struck. I needed some visibility into new ways of handling projects. Another thing you can do is to get the project team together for a kickoff can also get you some momentum. (The prospect of free food brings people out, so let them know that lunch will be delivered.)
Good luck.
1. Executive Summary
2. Project Description
2.1 Business Objectives
2.2 Solution Approach
3. Risks, Assumptions, & Constraints
4. Project Deliverables
4.1 Includes
4.2 Does Not Include
5. Project Schedule (in durations)
6. Project Control
6.1 Project Plans
6.2 Issue Management
6.3 Change Control
6.4 Communications and Reporting
7. Project Scope Signatures
Saving Changes...
Judith TurnerVice President| TCGWashington, Dc, United States
Sometimes fear works. (In fact, in politics it works most of the time, but then I'm in DC so we think of everything in terms of politics. I'll try not to digress from now on.)
I suggest a risk-identification session for your team, including the sponsors, champions, customers -- everyone who has a stake in this effort. What are the risks of staying on the current course? What could they mean to the project in time, money, etc.? How will you know that the risk is manifesting itself? What might you do to reduce, mitigate, or deal with it?
A brainstorming session, with whiteboards, pages up on the wall -- all the things that help people actually SEE what is happening -- can make this more real and more important.
By focusing on the dangers of continuing on your current path, you are likely to find that people start clamoring for leadership, for a project plan, for a schedule and task list... all the things that you know are needed but that seem to have slipped others' minds. And once you've got them asking you to provide it, you're golden!
Saving Changes...
"If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas."
