I went on a project management course recently. It was pretty 101 level but good enough for a n00b like me. It fired off a few thoughts that I want to dump here, not much insight here, but I want to write some more about it in another post.
What was interesting is that I feel that Agile is already accepted as being a great thing for business software, but this course basically ignored it on the grounds that
a) MOST people are still doing waterfall, in business or not
b) project planners sort of dislike it as it is hard to get the predicitability of waterfall.
a) is, I think, undeniable. b) is wrong but interesting. The problem (as I note below) is that people like waterfall because it feels precise and ordered, but when it breaks you only find out late, and their is no way for it to degrade gracefully.
The problem with Agile is, of course, little emphasis on documentation of design or user guides etc etc. The emphasis is on producing working software of known, high quality in a fixed time with all the flexibilty coming from precisely what functionality is delivered. To some people on the course (e.g., people writing firmware for tomahawk cruise missiles – no, really!) flexible function and no documentation is not an acceptable compromise, not matter how fast and cheap you can write the software!
* you must succeed and be seen to succeed: reporting is not an afterthought
* project manager’s role is to be looking ahead to the next phase, not working on the current set of tasks.
* checklists and templates are a kind of “project process lite”, not a substitute for real thought but provide something to react to. Most of project management is based on using what you already did that was similar. Good checklists/templates to have
* project stakeholders
* task estimation spreadsheet with 3-point estimate logic
* project milestone/gate reports
* risk checklist
* project owners are the people who have the right to judge whether the project was a success. project owners measure success in terms of things that were delivered 100%, not in terms of effort and tasks completed.
* a project goal statement is the definition of success; it is not high-level requirements list, nor a brief definition of the project owner’s problem, nor a desecription of the proposed solution.
* project stakeholders are any people who are impacted by the project.. not neccessarily people on the project team doing the work.
* by creating and publishing a project goala you may flush out a unhappy – and previoulsy unknown – stakeholders. we can then correct the project goal at very low cost in effort and political standing. It won’t be easy, but it will be easier than changing course later.
* it is better to have one project goal that everyone knows about. For projects that have stakeholders that are outside the organization – or have such disparate opinions and viewpoints – then multiple goal statements may be needed. Consider your honesty and what you do if you are “found out”.
* the project management lifecycle is separate from – but interlaced with – the software/system development lifecycle. The initial gathering of high-level project objectives are correlated to early requirements capture for development, but project goals are NOT the same as the user requirements that will be needed to create even high-level architecture of the system/software.
* the advantage of the waterfall model is that the project can proceed with many specialists who are coordinated by the project manager and work on different phases. only a few project “masters” are needed who understand all phases and work on the project for the whole cycle.
… the disadvantage of this is that different specialists will have little ownership and will not feel involved when their part is “done” and that can lead to different parts of the project team being at war (e.g., developers and
* project plan estimates are often nonsense: project managers pad time estimates for tasks in the plan and then senior managers cut these estimates arbitrarily because they know that they have been padded! How do we avoid these games and keep the plan a real tool for planning our projects? The answer: keep estimates ACCURATE but IMPRECISE by using a RANGE. The more imprecise the estimate is, the higher the risk. In some cases, highly imprecise or otherwise highly uncertain/risky tasks should be pushed towards the upper end of the estimate range. This means that only a few tasks are padded, and if senior management want to cut estimates for risky items then they can take responsibility for these specific cases!
* Building good, accurate plans is only possible where estimates are accurate. We must estimate then measure, re-estimate the remaining tasks and re-plan the project tasks to ensure that the project plan is still relevant. We must ensure that the estimate ranges are compared with the measured duration of the tasks so people can improve their estimation skills.
* Project planning and software design is inherently iterative; you must revisit earlier stages as you discover changes in the scope and deliverables of the project. The advantage of agile processes is that it recognises this explicitly; the disadvantage of waterfall is that it maintains the illusion of precision for too long; the iterative corrections are a footnote that we only discover late in the project.
* The balance between agile and waterfall is how many corrections we have to make; if the scope doesn’t change significantly then we can get away with the waterfall and get the advantages of simplicity, predictability and resourcing and staff with a single skill-set. If changes are constant or large then we need to recognise it and use agile which are unpredicatable (you don’t know what you will get, you only know that you will get it when the iteration ends) and requires highly-skilled, multi-talkented developers who are highly motivated.
* Reducing length of the critical path by overlapping dependent activities is possible but entails increased risk. (could be financial risk of sunk costs in a cancelled project)
* Risk control activities: prevention, reduction (of impact or probability), acceptance (absorbing risk), transfer (of control or the risk itself), contingency (what we do when the risk comes to pass).
* Research to try and evaluate probability or impact of risk is a TASK that should be on the project plan.
* If we find a risk but don’t want to carry out the risk control work but don’t want to accept the risk then we can use risk monitoring TRIPWIRES to regularly monitor some metric that will indicate increased probability or impact of a given risk. The effort of monitoring the metric is some small repeated task that will enable the FULL risk control task effort to be saved unless it is needed.
* Project reporting for milestones should be deliverable based, not task based. No project owner casres what effort you have put in, only what you have delivered 100% complete. A 90% complete feature is a missing feature. For reporting inside the team, you can be activity based, as long as people know what these activities are. For informal, regular (say daily or weekly) meetings you can report what people are doing now.
* remember the project manager’s job is to be ahead of the team preparing the ground ahead so you should be able to report what you will be doing NEXT. You should also be clearing behind the team ensuring that milestones/gates are truly delivered.