Project Schedule Must be Aggressive but Achievable

Usually, the word "aggressive" makes us worrying the same way as its synonyms violent, hostile and destructive. However, when it comes to a project schedule, the word "aggressive" should raise rather positive emotions, brought by its other synonyms: proactive, dynamic, vigorous, and optimized. Which also means the schedule is compressed, optimized, and coordinated; its risks are identified, registered (categorized and qualified), quantified, and resolution strategies are aligned contingency plans.

To support these definitions, certain dependencies need to be solved. The following framework provides a sequence of activities/dependencies for planning phase, which usually leads to an aggressive but achievable schedule.

1. Determine planning strategy:
   – determine the budget for planning phase and get the required sign off, if it wasn't defined in Project Charter or other project approval documentation;
   – determine and acquire a team to work with you on the project planning;
   – activities list for planning stage to be determined and coordinated with the management team;
   – verify with the project phases with project charter or another project approval document;
   – set up thresholds of estimations for each phace or part of the project – how detailed and precise your estimations should be (ROM or definitive);
   – coordinate with your parties (stakeholders, team) the model, tools, and techniques you will be using for estimating of the work;
   – verify if all stakeholders are identified by now; update the stakeholder register, if needed.
2. Requirements analysis:
   – gather, document and validate the requirements;
   – make requirements detailed enough to satisfy the thresholds agreed in planning strategy in step one;
   – categorize the requirements and set cross references by functional modules, business areas or other indicators – it will help to navigate through the list;
   – discuss and prioritize each requirement by importance, sequence of implementation and functional dependencies – this will help in case of scope revision;
   – solve interdependencies between the requirement;
   – clarified and verify the requirements with your teams and all stakeholders: sponsor, client, users, solution providers/vendors (optional at this stage).
3. Acquire sign off for a complete requirements document:
   – this sign-off event can be considered as a milestone;
   – communicate the finalized and signed requirements among stakeholders;
   – set the signed requirements as a baseline, so you could track changes or slippage.
4. Determine solution provider(s) and/or vendor(s), if applicable:
   – at this point, it is important to know what will be purchased or built in-house.
5. Coordinate with the solution providers/vendors the Costs (efforts/rates) and Timelines needed to analyse your requirements (most vendors charge for these analysis):
   – you should know how much your solution providers/vendors will charge your project for analysing the requirements and defining their costs;
   – verify if their costs fit your seed money for planning phase and coordinate the change if needed;
   – coordinate and document the terms of payments and process how your vendors will be charging – invoicing process.
6. Determine the Budget (seed money) and Schedule for Planning Phase of the project:
   – you will be needed some budget for planning phase of the project.
7. Develop the Project Scope Statement and acquire and sign-off:
   – the event of Project Scope Statement sign-off should be considered as a milestone;
   – further changes in the requirements can be done only via Change Request Process;
   – any change in already signed requirements and Project Scope Statement may lead to significant a slippage.
8. Create WBS and WBS Dictionary:
   – define all work packages and their deliverables;
   – the detailed information about WBS components needs to be described in WBS Dictionary.
9. Create Activities List:
   – list of activities for each work package.
10. Develop project activities Network Diagram:
    – a diagram of sequentially related activities will help to identify Critical Path of the project.
11. Determine Resource Requirements:
    – you shouldn't go further until the requirements for the resources are identified;
    – the efforts, rates/costs, and availability of the resources may heavily depend on the Resource Requirements.
12. Estimate Efforts and Costs:
    – this project management deliverable estimates the whole project or as determined in the coordinated Planning Strategy;
    (it can be a detailed estimation for whole project or only for the current phase, plus rough order magnitude (ROM) for the next phases;
    – usually this estimation is provided on the detailed level (+/- 5 or 10 % depends on the company standards).
13. Determine Critical Path of the project:
    – this is a key element in determining of duration of the planned project or phase and requires special attention.
14. Develop Project Schedule:
    – in content of this article, this is not the last activity in the first planning iteration; each of the following item usually affects the project schedule and can become critical;
    – in the first iteration, a draft schedule will be developed and verified against the following items;
    – throughout the next iterations, Project Schedule will be verified against any changes made in the previous or following items.
15. Develop Project Cost Budget:
    – budget is the one of easiest deliverables, if the previous steps have been done right;
    – this process puts together the costs of activities;
    – the numbers are summarized in work packages define Control Accounts, and total in Project Costs. After adding the contingency reserves, you can create your Budget Base Line. However, this is not it. There is a Management Reserve can be settled by your company – its incorporation into your plan will results the Project Cost Budget.
16. Determine Quality standards, processes and metrics:
    – quality may play significant role in other processes and the efforts required to maintain this items should be considered in each iteration; they rarely change from iteration to iteration, though.
17. Create Process improvement plan:
    – it may require to revise the project management processes in the benefits of the project and whole organization;
    – the process improvement may involve other people for reviewing, auditing, and analysing project quality.
18. All roles and responsibilities on the project are determined:
    – it is critical that roles for each activity of a type of activities to be determined;
    – despite no procurement activities to be done at this stage, availability of the resources and the timelines for their procurement needs to be considered via PMO processes;
    – RACI matrix is an essential tool in this item and should be applied for each activity.
19. Communication plan is created:
    – quite often this item doesn't get the required attention, while a few items in this document are critical;
    – special attention need to be pay for a complexity of the communication network.
20. Risks are identified, registered, qualified, quantified, and risk response strategies are planned:
    – risks as potential threats to the project need to be identified, registered, and qualified for further decision;
    – those risks that qualified for quantification, need to be analysed accordingly; probability and impact to be determined;
    – risk response strategies developed, appraised, coordinated with the related parties and approved by management;
    – project contingency is determined/updated based on risk response efforts and time (schedule), and costs (project cost and cost budget to be updated);
    – in some cases the project scope and quality can be affected by risks too.
21. Cycle revisions throughout iterations:
    – identify, document, and debate options – go through a solution selection process;
    – the drafted documents, delivered by activities from #2 to #20 needs to be thoroughly reviewed, revised (if required); the numbers and dates to be adjusted against changes;
    – how many iterations the revision should go through? The answer is simple, until the thresholds of estimations are met and schedule become aggressive and achievable enough to be named realistic.
22. Sign off:
    – after a few more activities that do not make effect on your schedule, like preparing the Procurement Documents and creating Change Management Plan, get your Project Management (integrated) Plan signed, and your are good to go further.
23. Communicating (as per your communication plan) and Thanking:
    – do not forget to thanking each and all persons, who've been contributing to the work, do it during each activity;
    – do not forget to informing each contributor about reaching the final consensus;
    – do not forget to thank all contributors, when the final deliverables have been signed off; be specific about the value of each or at least major contributors.
24. Don't give up identifying, documenting, promoting, and applying best practices and making things right in the best of the business interests.

This list of estimating and planning activities doesn't provide all the details here, but puts together a picture of what makes the project schedules being aggressive and achievable. The provocative words "Aggressive Schedule" in PMI language mean that the schedule is compressed, and "Achievable" – thoroughly optimized; together, these words define schedule Realistic.

The framework, outlined in this article, is sharpen for certain types of projects in large systems. Conceptually, it is useful in many industries, where even a small change may become significant in term of efforts (expenses), overall time (duration), and some other aspects. It is the project manager's responsibility to select, adjust or improve the project management framework (processes, procedures, etc.) for their specific projects. There is no single framework suites all types of projects – that's why the project management models are so different.

I encourage to debate your experiences in putting project schedules together and making them robust and realistic; this is a good opportunity to contribute to project management and make difference.