I am a relatively new PM and are organization is in it's infancy with the PM discipline. For now, we are keeping our project plans simple with a basic high-level task structure of:
- Requirements
- Design
- Development
- Testing
- Implementation
This works fine if we are building something and implementing it ALL at the same time. Here's my situation and question.
The life of the project is about 1 year. The last deliverable MUST be implemented by Oct 2010 (I work in government and this project is a mandate from our legislature). We have to implement certain "pieces" so as to be available to the public at specific times. I'm treating those pieces that have to be implemented at each specified time as milestones. There will different design, dev, and testing work for each milestone.
How do I present that in the project plan? Based on the structure I listed above, do I create the design, dev, and testing activies for EACH milestone or is there a better way to structure my plan?
Activities are performed to create deliverables which have to be provided on a schedule. So - Think of milestones as a date when a deliverable must be completed.
For example - in each of your task structures below - you will be performing 1 or more activities/tasks to create stuff: a requirements document, or scrum notes, or approvals to proceed, or something. Those deliverables will probably need to occur in a certain order - and one may be dependent on another one - so each of those deliverables are scheduled to happen in a sequence - and they have to be completed by a certain date so that you remain on schedule.
I like to work backwards from my high level deliverables - that way I can identify what work has to be performed to make them. It becomes easier to identify if something has to be completed first or second, which helps with the schedule development. Once that's done it should help identify in what order the deliverables need be produced - which will identify the date on which they need to be completed.
In your case - you already know the end date. So your challenge is to work backwards from when you have to be done identifying the milestone dates for the deliverables going backwards. The key part of solving the problem is fully understanding what work has to be completed, and in which order it has to fall into.
Lastly - you have certain pieces that will be seen by the public. Since these major milestones probably have either dates or some many days from completion - understanding what work needs to be done to provide those will be a critical success factor.
So how to represent your plan? Activities contain tasks which produce deliverables which occur on a certain date(milestone) and based on their interdependencies which will create your schedule.
Clear as mud? Saving Changes...
Michael SchubertSenior Manager Employee Portal Development| McKessonCumming, Ga, United States
It sounds like you are confusing milestones with deadlines.
Build your plan - identify all the dependencies with your tasks, assign resources and place your milestones on the plan as markers of events or work complete (e.g. Design Signed Off; Code Frozen; etc). Avoid the temptation of constraining tasks by date if possible. You know the start date of your project - you are trying to determine the finish date. The rest of the dates should be event driven based on the start or completion of other tasks.
The legislature mandated your finish date, but they aren't going to stop by the office and help you code for it. Your job is to track the work performed and make sure you will meet the deadline. If tasks take longer than anticipated, scope changes, you lose a resource, etc.. you can see what the impact on delivery will be and then plan accordingly (hire people, work overtime, lobby for an amendment).
This approach is pretty straightforward to implement in MS project. You can indicate your deadlines via the "deadline" date field and you will then have a visual indicator when tasks have not been completed by the deadline. Identify the key driver tasks throughout the life of your project and set the intermediate project deadlines for those tasks and you will have a good early warning system to detect when you are tracking toward missing your mandated finish date. Saving Changes...
Matt KirchmanDirector, Digital Technology Programs and Vendor Management| Oshkosh CorporationWisconsin, United States
I agree with Donald. Focus on your main deliverables, and build plans to attack each of them as a separate work stream. This may require some intensive planning up front if you have not already determined what those major deliverables are. Delivery of each of those will be major milestones in your overall project schedule.
The next decision you have is how to actually attack each deliverable. Are you going to focus on a traditional project delivery model (i.e. waterfall) or will an Agile-based (extreme, SCRUM, etc.) approach work for you? Perhaps it will be some sort of hybrid approach. Given the highly-public nature of some of your outputs, you will have to really focus on execution and aligning the right type and number of resources to your critical work streams. And remember, as a project manager, your job is to be a little bit of a skeptic. You'll need to really dig in to understanding estimates and deadline commitments to determine if they are realistic, and then you will have to be proactive in removing hurdles to the team's success. Saving Changes...
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Hi Ana
Donald and Matt have fair points. In addition I would like to add since you have a fixed delviery date, a couple of things:
- Decision points
Appear to be the same as milestones and will often coincide. A decision point is when you will not be able to make the final milestone to present an alternative to be able to go live on the fixed date. This can be reducing the scope by deliverign certain pieces later, potentially including temporarily manual procedures to meet the requirements from legislature. E.g. hiring a number of external resources to implement a temporary solution cost time but also require some logisitcs, setting up suffficient equipped desk space.
COming up with alternative plans will drive your decision points. From your decision point it will be easy todetermien where you need to be in the project which than becomes a milestone
- Risk management
AS soon you have yoru decision points you need to assess the risks and run a very tight risk management process during the project to have the early signs of potential missing milestones. The earlier discovered the more options are available to mitigate the risk including escalating to senior management
Hopes this helps Hans Saving Changes...
Huw EvansSenior Manager, Projects and Partnerships| Vicinity CentresMount Waverley, Vic, Australia
I think I agree with the others, but let me state it using the terms you've used:
The "pieces" that have to be made available are your deliverables. These should represent the main structure of your reporting. Within each of these deliverables you should have sub-deliverables that make sense to that deliverable, eg. your Req, Design, Dev, Test & Implementation sub-headings.
There is no point lumping together development tasks for two separate streams of work.
Saving Changes...
Paul NaybourFounder and Director| Parallel Project TrainingNailsworth, United Kingdom
This is a common problem for many projects; you have multiple deliverable dates and targets. In fact you will most likely have multiple critical paths each leading to a deliverable milestone. As everyone else has said you need to map out the activities leading to each deliverable, using the phases you discussed. You can then plan out the path to each deliverable leading to deliverable and also dependencies between each work package. To flag up the multiple critical paths you will need to impose a early finis constraint on each of the intermediate deliverables. If you are using Microsoft project 2007 you can also show a target date for each target milestone.
Online APM Based Project Management Training Saving Changes...
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
On reading your paragraph you are detailing that certain “pieces” will be available at specific times. Therefore I am assuming you mean there are separate bits of function / product that will be delivered that somebody will receive a benefit from. These are projects in their own right in my view.
Assuming you will use MS Project. What you have is a programme made up of project elements with have their own activities to complete (design Dev etc). Therefore do not put all of this into one *.mpp file for example but break them out into separate files per deliverable/product/piece.
Have a master Project file where you capture the programme start up tasks and final programme closure tasks for example, then insert the individual projects into your master project file. (be sure to insert them in spaced rows e.g. between 4&6 8&9)
Manage the individual phases as separate projects as they will all have their own risks and issue due to the different times (e.g. holidays), different deliveries (e.g. UAT’s). This way you will keep people focused on the first delivery, then the next etc which should be the dependant delivery for the remainder programme.
Saving Changes...
You have included "requirements" in your task structure. To me, this suggests that you do not yet know the requirements and want to develop a project schedule - this is a sure-fire recipe for a likely disaster. In my opinion, you should embark on scheduling only after you have understood the requirements crystal clear and had them signed off by the client (or all concerned). You will be able to develop a better schedule if you know the requirements. The requirements should focus on the functional aspects. Requirements of GUI are more prone to change and are best elicited/finalized visually. I would suggest that you keep presenting mock screens/forms to your clients and appropriately include only those in your requirements document that they finalize. No matter whether you use MS Project or whatever tool, you'll never be able to come up with good estimates/schedule if your are unclear about any of your requirements. Approach the gray/risk areas, where you think you'll need technology study, for example, with bottom-up development and factor those out - do NOT include those gray/risk areas into your schedule and deal with them up-front. You can schedule only those aspects that you are able to develop NOW. If you think you can pick up a technology fast and still able to deliver on time then you are plunging into a gray area - carry out development in that area first in a bottom-up manner before incorporating it into your schedule. Saving Changes...
In my earlier post, I just wanted to say that everything else in your "high-level task structure" depends on _clear_ requirements. For example, it is the requirements that will drive your test cases. Saving Changes...
Regarding the gray areas, you can mitigate risk and cut down on your development time by hiring people who are experts on those gray/risk areas. Another way of mitigating risk is iterative development and frequent deliverables. I would suggest that you take your end-users into the loop as early as possible so that you fail early - any bugs or necessary changes to be made come to the surface early that way and you get plenty of time to fix. Saving Changes...
"We are ashamed of everything that is real about us; ashamed of ourselves, of our relatives, of our incomes, of our accents, of our opinions, of our experience, just as we are ashamed of our naked skins."
