Easy IT elements – Plans explained

He who fails to plan is planning to fail

This quote and similar variations is attributed to Benjamin Franklin, Winston Churchill, and many others – so who am I to argue!

Plans can have a very broad range of purposes, they come in different sizes, levels of detail and sophistication; from a simple aspiration/goal or ‘to do’ list at one end of the scale to world domination at the other end! The IT elementary school is interested somewhere in the middle of this range, non-trivial one-off activities (Projects) that deliver business change or innovation, usually with a computing, technology or software dimension.

Here is my working definition:

A plan provides a schedule of actions and outcomes, with target dates, resource demands, and dependencies necessary to achieve the stated project aim and objectives.

Firstly, I want to explain some of the common terms involved.

A plan is the main output of the planning process, and typically contains:

• A schedule or timeline, with aspirational target dates for outcomes or the ‘delivery’ of the end product(s), i.e. deliverables.
• Interim milestones that allow progress against targets to be measured at significant way-points, or possibly to make a decision on the next steps or alternative options.
• The activities or work packages (work breakdown structure) to be undertaken. Discrete tasks are represented as the horizontal bars in the example below.
• Tasks normally have a notional size that depends on the planning approach or method used. Planned tasks may have a duration (e.g. ‘x’ days), or they could be defined by fixed start and/or end dates (a time-box), the finished product/outcome, or the resources (people, materials, money) to be assigned or expended. In most cases some combination of these 4 measures is used to produce an acceptable and hopefully a realistic and achievable plan.
• Internal and external dependencies. For example, in order to start or finish a task something might be needed from another internal group; an output from another planned task, a decision, or something from outside of the immediate project team or remit. Obviously external things are harder to control, and may be subject to contractual obligations.

Here is a very simple illustration of some of these concepts.

A key omission from this anatomy of a project plan is some statement of the expected outcomes of the whole endeavor, which is normally part of a Project or Programme scope or the objectives of a Strategic initiative. A plan is an idealized model of what could happen in the future given a number of assumptions and, often in hope rather that expectation!

Meanwhile back in the real world

Once a plan has been produced and agreed by the sponsor and main stakeholders and the money and other resources are in place then it can be executed. A Project Manager may lead both stages, but equally they can be team efforts. The tough part starts with the need to deliver against the promises invested in the plan. For example, managing the many things that could prevent person/group A delivering widget X to group B on such-and-such a date.

This doesn’t all happen by magic; the plan needs to be monitored, updated with real actual rather than planned activities, and if necessary modified when unexpected things happen. Deadlines or dependencies could be missed; deliverables may not be produced on time or fail to meet the required acceptance criteria or quality measures. This latter situation is covered separately as part of the Testing module.

One of the advantages of planning & monitoring and the use of software tools such as Microsoft Project, is that problems may be spotted earlier than by simply trusting to luck or a looser verbal commitment. Only when such slippage is spotted, or can be predicted, can it be remedied, for example by re-planning, changing dates and project outcomes (‘de-scoping’), adding resources, or even stopping work altogether.

The above description of a plan and the planning process assumes adoption of a GANTT-style chart*, the most popular approach used for IT and software Projects. However, other planning/scheduling tools and techniques are available including PERT (Program Evaluation and Review Technique) and ‘Critical Path Analysis’ that are beyond the scope of this module. Plans can appear wherever complex tasks require the coordination of multiple groups, resources and dependencies, such as marketing campaigns and product launches, office moves, building projects, event management etc.

(*Ed. not an acronym, should be ‘Gantt’, after Henry Gantt and the bar chart that he developed in 1910)

As with a lot of other concepts in the table of IT elements, the thinking and process required to produce something is as important as the finished product itself. The same applies to Models/modelling, Requirements/requirements analysis, Stakeholders/stakeholder analysis and Design/designing. These are fundamentally human activities that require the interpretation of needs, motivations and behaviours to work effectively, as well as the engagement of various interested parties. Each Plan is unique and specific to its intended use within an organisation, industry and Project team.

I hope you found this short introduction useful, there are many more advanced tools and techniques for the experienced planner and Project Manager to learn and apply. Where do you want to go now in the table of IT elements?

@ITelementary

(c) 2015 Antony Lawrence CBA Ltd.