You are on page 1of 16

Project management, tools, process, plans and project planning tips Here are rules, processes and tools

for project planning and project management. While project management skills are obviously important for project managers, interestingly the methods and tools that project managers use can be helpful for everyone. A 'task' does not necessarily have to be called a 'project' in order for project management methods to be very useful in its planning and implementation. Even the smallest task can benefit from the use of a well-chosen project management technique or tool, especially in the planning stage. Any task that requires some preparation to achieve a successful outcome, will probably be done better by using a few project management methods somewhere in the process. Project management methods can help in the planning and managing of all sorts of tasks, especially complex activities. Project management is chiefly associated with planning and managing change in an organization, but a project can also be something unrelated to business - even a domestic situation, such as moving house, or planning a wedding. Project management methods and tools can therefore be useful far more widely than people assume. Project management techniques and project planning tools are useful for any tasks in which different outcomes are possible - where risks of problems and failures exist - and so require planning and assessing options, and organizing activities and resources to deliver a successful result. Projects can be various shapes and sizes, from the small and straightforward to extremely large and highly complex. In organizations and businesses, project management can be concerned with anything, particularly introducing or changing things, in any area or function, for example:



Successful project management, for projects large or small, tends to follow the process outlined below. The same principles, used selectively and appropriately, also apply to smaller tasks. Project management techniques are not just for project managers - they are available for anyone to use. project management process 1. Agree precise specification for the project - 'Terms of Reference' 2. Plan the project - time, team, activities, resources, financials - using suitable project management tools. 3. Communicate the project plan to your project team - and to any other interested people and groups. 4. Agree and delegate project actions. 5. Manage and motivate - inform, encourage, enable the project team. 6. Check, measure, monitor, review project progress - adjust project plans, and inform the project team and others. 7. Complete project - review and report on project performance; give praise and thanks to the project team. 8. Project follow-up - train, support, measure and report results and benefits. 1 - agree precise specification (terms of reference) for the project Often called the project 'terms of reference', the project specification should be an accurate description of what the project aims to achieve, and the criteria and flexibilities involved, its parameters, scope, range, outputs, sources, participants, budgets and timescales (beware - see note below about planning timescales). Usually the project manager must consult with others and then agree the project specification with superiors, or with relevant authorities. The specification may involve several drafts before it is agreed. A project specification is essential in that it creates a measurable accountability for

anyone wishing at any time to assess how the project is going, or its success on completion. Project terms of reference also provide an essential discipline and framework to keep the project on track, and concerned with the original agreed aims and parameters. A properly formulated and agreed project specification also protects the project manager from being held to account for issues that are outside the original scope of the project or beyond the project manager's control. This is the stage to agree special conditions or exceptions with those in authority. Once you've published the terms of reference you have created a very firm set of expectations by which you will be judged. So if you have any concerns, or want to renegotiate, now's the time to do it. The largest projects can require several weeks to produce and agree project terms of reference. Most normal business projects however require a few days thinking and consulting to produce a suitable project specification. Establishing and agreeing a project specification is an important process even if your task is simple one. A template for a project specification: 1. Describe purpose, aims and deliverables. 2. State parameters (timescales, budgets, range, scope, territory, authority). 3. State people involved and the way the team will work (frequency of meetings, decisionmaking process). 4. Establish 'break-points' at which to review and check progress, and how progress and results will be measured. Separately the acronym BOSCARDET provides a useful example structure for Terms of Reference headings/sections: Background, Objectives, Scope, Constraints, Assumptions, Reporting, Dependencies, Estimates, Timescales. This structure contains no specific heading for costs/budgets - these considerations can be included within 'Constraints' or 'Estimates'. Since projects (and other activities requiring Terms of Reference) vary considerably there is no standard universal structure for a Terms of Reference document. The responsibility lies with the project manager or leader to ensure all relevant and necessary issues are included, and this local interpretation tends to imply TOR headings and document structure. Brainstorming can be a helpful process by which all relevant Terms of Reference criteria can be indentified and structured. Organizations may have standard TOR structures, such as the BOSCARDET example, which it is sensible to use where applicable, mindful of risks of omission or over-complication that can arise when following standard practice. See also Terms of Reference in the business dictionary section.



modelling and quality management, which contain related tools and methods aside from the main project management models shown below. The tools here each have their strengths and particular purposes, summarised as a basic guide in the matrix below. Matrix key: B = Brainstorming F = Fishbone/Ishikawa Diagrams *** ** main optional/secondary tool tool

C = Critical Path Analysis Flow Diagrams G = Gantt Charts

* - sometimes useful B Project brainstorming and initial concepts, ideas, structures, aims, etc Gathering and identifying all elements, especially causal and hidden factors Scheduling and timescales Identifying and sequencing parallel and interdependent activities and stages Financials - costings, budgets, revenues, profits, variances, etc Monitoring, forecasting, reporting Troubleshooting, problem identification, diagnosis and solutions 'Snapshot' or 'map' overview - non-sequential, non-scheduled Format for communications, presentations, updates, progress reports, etc brainstorming Brainstorming is usually the first crucial creative stage of the project management and project planning process. See the brainstorming method in detail and explained separately, because it many other useful applications outside of project management. Unlike most project management skills and methods, the first stages of the brainstorming process is ideally a free-thinking and random technique. Consequently it can be overlooked or under-utilized because it not a natural approach for many people whose mains strengths are in systems and processes. Consequently this stage of the project planning process can benefit from being facilitated by a team member able to manage such a session, specifically to help very organised people to think randomly and creatively. fishbone diagrams Fishbone diagrams are chiefly used in quality management fault-detection, and in business process improvement, especially in manufacturing and production, but the model is also very useful in project management planning and task management generally. ** ** * * * * F C G

*** **

*** ** ** ***


*** ** *** * *


Within project management fishbone diagrams are useful for early planning, notably when gathering and organising factors, for example during brainstorming. Fishbone diagrams are very good for identifying hidden factors which can be significant in enabling larger activities, resources areas, or parts of a process. Fishbone diagrams are not good for scheduling or showing interdependent time-critical factors. Fishbone diagrams are also called 'cause and effect diagrams' and Ishikawa diagrams, after Kaoru Ishikawa (1915-89), a Japanese professor specialising in industrial quality management and engineering who devised the technique in the 1960s. Ishikawa's diagram became known as a fishbone diagram, obviously, because it looks like a fishbone:
A fishbone diagram has a central spine running left to right, around which is built a map of factors which contribute to the final result (or problem). For each project the main categories of factors are identified and shown as the main 'bones' leading to the spine. Into each category can be drawn 'primary' elements (shown as or P factors in the



factors if necessary.

The diagram above is a very simple one. Typically fishbone diagrams have six or more main bones feeding into the spine. Other main category factors can include Environment, Management, Systems, Training, Legal, etc. The categories used in a fishbone diagram should be whatever makes sense for the project. Various standard category sets exist for different industrial applications, however it is important that your chosen structure is right for your own situation, rather than taking a standard set of category headings and hoping that it fits. At a simple level the fishbone diagram is a very effective planning model and tool - especially for 'mapping' an entire operation. Where a fishbone diagram is used for project planning of course the 'Effect' is shown as an aim or outcome or result, not a problem. The 'Problem' term is used in fault diagnosis and in quality management problem-solving. Some fishbone diagrams can become very complex indeed, which is common in specialised quality management areas, especially where systems are computerised. This model, and the critical path analysis diagram are similar to the even more complex diagrams used on business process modelling within areas of business planning and and business process improvement. project critical path analysis (flow diagram or chart) 'Critical Path Analysis' sounds very complicated, but it's a very logical and effective method for planning and managing complex projects. A critical path analysis is normally shown as a flow diagram, whose format is linear (organised in a line), and specifically a time-line. Critical Path Analysis is also called Critical Path Method - it's the same thing - and the terms are commonly abbreviated, to CPA and CPM. A commonly used tool within Critical Path Analysis is PERT (Program/Programme/Project Evaluation and Review Technique) which is a specialised method for identifying related and interdependent activities and events, especially where a big project may contain hundreds or thousands of connected elements. PERT is not normally relevant in simple projects, but any project of considerable size and complexity, particularly when timings and interdependency issues are crucial, can benefit from the detailed analysis enabled by PERT methods. PERT analysis commonly feeds into Critical Path Analysis and to other broader project management systems, such as those mentioned here. Critical Path Analysis flow diagrams are very good for showing interdependent factors whose timings overlap or coincide. They also enable a plan to be scheduled according to a timescale.






accountability. Your project will also benefit from input and consultation from relevant people at an early stage. Also consider how best to communicate the aims and approach of your project to others in your organization and wider network. Your project 'team' can extend more widely than you might first imagine. Consider all the possible 'stakeholders' - those who have an interest in your project and the areas it touches and needs to attract support or tolerance. Involvement and communication are vital for cooperation and support. Failing to communicate to people (who might have no great input, but whose cooperation is crucial) is a common reason for arousing suspicion and objections, defensiveness or resistance. 4 - agree and delegate project actions Your plan will have identified those responsible for each activity. Activities need to be very clearly described, including all relevant parameters, timescales, costs, and deliverables. Use the SMART acronym to help you delegate tasks properly. See the delegation tips and processes. Using proper delegation methods is vital for successful project management involving teams. When delegated tasks fail this is typically because they have not been explained clearly, agreed with the other person, or supported and checked while in progress. So publish the full plan to all in the team, and consider carefully how to delegate medium-to-longterm tasks in light of team members' forward-planning capabilities. Long-term complex projects need to be planned in more detail, and great care must be taken in delegating and supporting them. Only delegate tasks which pass the SMART test. Other useful materials to help understand team delegation are theTannenbaum and Schmidt Continuum, and Tuckman's group forming/performing model. The Johari Window model is also an excellent review framework for quickly checking or reminding about mutual awareness among team members in large complex projects, where there is often a risk of project fragmentation and people 'doing their own thing' in blissful isolation - which seriously undermines even the best planned projects. 5 - manage, motivate, inform, encourage, enable the project team Manage the team and activities in meetings, communicating, supporting, and helping with decisions (but not making them for people who can make them for themselves). 'Praise loudly; blame softly.' (a wonderful maxim attributed to Catherine the Great). One of the big challenges for a project manager is deciding how much freedom to give for each delegated activity. Tight parameters and lots of checking are necessary for inexperienced people who like clear instructions, but this approach is the kiss of death to experienced, entrepreneurial and creative people. They need a wider brief, more freedom, and less checking. Manage these people by the


This is particularly so in very political environments, and/or where projects benefits have relatively low visibility and meaning to stakeholders (staff, customers, investors, etc), especially if the project also has very high costs, as ICT projects tend to do. ICT (information and communications technology) projects often are like this - low visibility of benefits but very high costs, and also very high stress and risk levels too. Project management almost always involves change management too, within which it's very important to consider the effects of the project on people who have to adapt to the change. There is often a training or education need. There will almost certainly be an explanation need, in which for example methods like team briefing have prove very useful. Whatever, when you are focused on project management it is easy to forget or ignore that many people are affected in some way by the results of the project. Change is difficult, even when it is good and for right reasons. Remembering this during and at the end of your project will help you achieve a project that is well received, as well as successful purely in project management terms. Someone once said "Don't you love it when a plan comes together?" It's true. As project manager, to be at the end of a project and to report that the project plan has been fully met, on time and on budget, is a significant achievement, whatever the project size and complexity. The mix of skills required are such that good project managers can manage anything. amusing project management analogies To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the project manager, the glass is twice as big as it needs to be. A clergyman, a doctor and a project manager were playing golf together one day and were waiting for a particularly slow group ahead. The project manager exclaimed, "What's with these people? We've been waiting over half and hour! It's a complete disgrace." The doctor agreed, "They're hopeless, I've never seen such a rabble on a golf course." The clergyman spotted the approaching greenkeeper and asked him what was going on, "What's happening with that group ahead of us? They're surely too slow and useless to be playing, aren't they?" The greenkeeper replied, "Oh, yes, that's a group of blind fire-fighters. They lost their sight saving our clubhouse from a fire last year, so we always let them play for free anytime." The three golfers fell silent for a moment. The clergyman said, "Oh dear, that's so sad. I shall say some special prayers for them tonight." The doctor added, rather meekly, "That's a good thought. I'll get in touch with an ophthalmic surgeon friend of mine to see if there's anything that can be done for them." After
