Risk Log – what should be in it?

There are many different Risk Log templates available, some more complex or simple than others. But what do we really need to record?

Often we don’t have much choice about what we record in our Risk Log, because we have to use a corporate template, which might be more or less fit for purpose. Some are much heavy-weight than others. For example, I just counted the number of columns in the Risk Log template where I am working currently and there are 35!

That is too many for me, I am much more of a minimalist. (Can one be more of a minimalist)? One of my pet hates is having to keep scrolling backwards and forwards across a record because there are too many columns – and in my experience, most of the time, most columns are empty but the useful ones are placed apart from each other.

I want the log to be useful to me as a PM – I am the one who should use it the most. So, we need a simple Excel spreadsheet with the following:

ID – We need a unique reference. Start at 1 and keep going.

Status – We only need three values – Open, Closed, Realised. Realised means a Risk has happened and has become an Issue. Closed means a Risk has passed without occurring.

Risk Description – This is the Event, Reason, Outcome descriptive text discussed in the previous post.

Probability – How likely is the Risk? No more sophisticated granularity than High-Medium-Low is needed, using a coloured RAG status visually so we can quickly find the Reds. Some places prefer a percentage. This suggests a level of precision that doesn’t exist but we need it if we want to work out a cost. I suggest using something like 50-25-10 for HML if we have to give a number; too often in the past I have wasted time discussing whether a Risk Probability should be 20% or 30%. Sometimes more granularity is needed to work out a contingency cost for a budget, otherwise it’s not worth worrying about it.

Impact – Again, use a RAG status for High-Medium-Low. Some places prefer to split impact on Cost and Time as they can vary – but we can just write that in the description. We only need the RAG status to help us quickly locate our main risks; showing Cost/Time separately makes them harder to spot. Just take an average view of both combined (they are often similar anyway).

In practice, I have found I use the RAG status to filter the key risks e.g. for management reviews. Simpler is better here – all we want is a way to identify the most critical Risks, as PMs we probably know what they are anyway, and they ought to be the Red ones!

Action Plan – sometimes there are separate fields for mitigation and response, but I don’t see the need. Often there is more than one mitigation or response depending on the circumstances, so I don’t see the problem with recording both together in a single box.

Comments – this is the one I find most useful (and is sometimes not even present) – just make a note every time we do something. Always start a comment with a date (and initials if more than one person ever updates the log). Sometimes a busy Risk might get quite deep but I find having all comments in one place more than makes up for it.

I might also have columns for some or all of date opened, last updated and date closed but only if I’m going to want to sort by date. Otherwise we might just as well use the comments field in the same way to record opening and closing

So – I have just seven columns. This means my log fits nicely within a single screen/page so I can see everything at once. And it can easily be printed out.

Recording Risk

I have already written about the importance of a Risk Log, so now we have one, what should we record?

Often we write them down in shorthand. To quote a couple of examples I have come across recently in actual logs:

“Lack of wider business engagement”
“Staff retention proves difficult”

It is certainly more important to record the Risk first before it is forgotten and refine the wording later (as part of the weekly review I mentioned previously). A well-phrased risk statement should allow somebody with minimal knowledge of the project situation to be able to understand exactly what might happen and why. If you are like me and can barely remember what happened last week, let alone six months ago, you will then easily recall the risk detail and what to do about it several months later when it actually happens.

Some places I have worked have adopted a very strict policy, sometime enforced by templates. A common template wording is “There is a risk that (event happens…) because (cause…) with the result that (outcome…)”.

Let’s look at these three points in turn:

Event – what could happen. Sometimes it can be difficult to separate the event from the outcome – we might be late because something takes longer than planned. Often in software it comes down to “we underestimated”, all other causes of risk are much less common (but it’s not usually acceptable to say so).

Cause – why the event has happened. It is important because we can identify mitigating actions that we may be able adopt to make the event less likely. It may also be that our assessment of likelihood varies for different causes. So let’s think about at another recent example I came across which had no cause given:
“There is a risk that the Client review of the Requirements documentation highlights major concerns and results in significant additional effort to address issues” (no cause given)

It may be that we have missed out something fundamental. Is the cause lack of agreement (or understanding) of project scope? Is it that the expectations of the format or structure of the document are misaligned? Or is it simply that the requirements team are not skilled enough and have done a sub-standard job? Even though all causes have the same result (more effort and time), we may want to assess and record different mitigating actions.

Outcome – the consequences of the event. In the example above, irrespective of cause there might be a delay while we deal with some issues, and I might want to add some contingency time in the plan. Experience suggest that there will always be at least a small number of review comments that need to be addressed so it is sensible to plan some time to address comments. So here we should consider if we need to factor in any additional time over and above our planned contingency. Some outcomes might be more serious than others, e.g. if we have misunderstood scope, we may have to go right back to the beginning, whereas if the document has been written by an inexperienced team member, maybe a few days effort from somebody more experienced and another review cycle will be enough to recover the situation.

Personally, I wouldn’t get too hung up about the exact wording, as following a rigid format can sometimes get convoluted. (Worst of all is when the log has a separate column to enforce an entry for each part which then means that three lots of cutting and pasting is needed every time you want to transfer a Risk to a status report). It’s better to be concise rather than always following a precise formula, but I would want to make sure it answers all three aspects (event, cause, outcome) and is expressed in language that can be understood by somebody without any detailed knowledge of the project.

See Also:
Quick summary from Better Projects

Risk Granularity

I have recently started a new project in its early stages so have been thinking how best to set it up for success. One question that I as Project Manager have had to address is the approach to be taken to the level of granularity of Risk to be recorded. Do we take a very detailed description of each specific risk, carefully costed and regularly updated, or a very high level approach, with very few risks with a crude finger in the air estimate of impact? I have worked in places that have adopted both extremes as well as somewhere in between.

The culture of the organisation is important; my experience of engineering companies is they are much more risk averse and expect a much tighter level of detail than many others. The stage of the project is relevant – during the early stages much detail is unknown so most Risks will reflect this by being at a very high level.

In commercial projects most Risks can be often summarised as “we underestimated” and the main purpose of the Risk Log (especially early in the project when all estimates are suspect) is to justify a price with additional contingency. We might simply add a percentage figure to certain cost elements to allow for our own uncertainty, unless there are some obvious specific big ticket items straight away.

At one extreme, I have worked on programmes and projects where the Risk Log was extensive, containing lots of carefully delineated and costed risks, which inevitably took a lot of time and effort in curation. Why would you want to do this? One reason on a larger project is that even small bits of Risk can add up to quite significant amounts of money. Depending on the way Risk is managed. It may also be that as a PM you are automatically authorised to spend a stated amount of money to mitigate the Risk, in which case it needs to be clearly defined so there is no argument when it happens.

On the other hand, there is a great temptation to turn Risk Management into a cottage industry, especially on larger programmes where there is a Programme Management Office with sufficient resource to manage a heavy-weight process. (I have also noticed that the programmes I’ve worked on that have had a very rigorous process tend to be failing projects… or maybe that’s just me being cynical).

At the other extreme, I have worked elsewhere where the expectation was that there would be no more than about five Risks adding up to about 10% of the total contract value, which between them would be general enough to cover most eventualities. Typical examples would be – unable to recruit a team at the expected cost, activities take longer than planned, or a key team member resigns incurring cost to recruit and train a replacement. In general on projects like this the Project Manager is expected to hit the budget and manage the deliverables vigorously, and the contingency is there to give enough wriggle room to make sure. In these projects, provided we are on time/budget, I have rarely been under pressure to pay much attention to the Risk Register, and when we have stepped out of the good zone it has usually been down to a specific Risk materialising which we had to deal with, and move on.

So, if not forced to follow an approach by existing practice to follow, what is the right amount to record? My view is to treat the Risk Log as a worry list (and follow Seth Godin’s advice not to worry too much), particularly those of the higher impact ones that are most likely to happen in the next few months and that you are actually in a position to influence. You should briefly note other lesser impact or more distant risks when you think of them in case things change, but don’t spend too much time on them. Focus on the key risks use the log a reminder of when things might happen, what you intend to do about it, note when you highlight them in reports, and keep enough detail to demonstrate your thinking without being a burden. By focusing on the key risks in sufficient detail you will find the log is a helpful tool.

Risk Log – time consuming red tape?

Despite being an experienced Project Manager I sometimes feel I could do better at formal Risk Management and on reflection I’m probably not alone.

My experience of Risk Management in practice is that from time to time I work on a project where suddenly it comes under a lot of scrutiny, everyone looks very closely at Risks for a while, then interest wanes and it is forgotten again. When this happens it is easy to view maintaining the Risk Log as a bureaucratic overhead.

Formal project management literature advises that if we are carrying out Risk Management seriously we should maintain a detailed Risk Log (or Register), which should record all the potential risks that might affect our project, and what we propose to do if they occur. We should review them regularly and update them as things change. I have spent most of my career working for large consultancies or other large organisations, all of whom mandate a formal process and provide extensive guidance including an all-encompassing Risk Log, which our Project Management Plan duly confirms we maintain on a regular basis.

In practice most projects I have worked on have been far less diligent. I have rarely inherited a project in mid-flight with a comprehensive and up-to-date Risk Log. The exceptions were either large programmes where there was a PMO team with somebody dedicated to maintaining Risks and Issues, or where project status was so Red that a full Risk Review exercise was needed. Otherwise, the mere existence of a log with some entries in it has been deemed as compliant, but of course having a log does not equate to managing risks.

In practice like many PMs I am continually calibrating the more likely risks in my head on a constant basis. Much of the time we don’t look at the log; we keep track of (most) risks that are likely to occur within the current planning horizon and deal with them as needed. Sometimes weekly reports highlight some of them. But what about further ahead? Keeping a log does provide some immediate benefits to a PM.

Firstly, it provides a list of all the things you should be worrying about in a single place. Get into the habit of reviewing Risks regularly. Mike Clayton’s advice (1) is to review Risks every day (where does he find the time?) – I found a weekly slot worked better for me. I set aside time in my calendar to review the entire log prior to the weekly reporting cycle. A formal weekly review takes no more time than trying to report on Risks haphazardly. I also include Risks as an Agenda item on my weekly team meeting, which is usually on a different day of the week. (The Agile daily standup question “what is preventing me from getting my job done” will also identify some risks although it tends to have a shorter term focus). This can be combined with reviewing Issues at the same time as there is overlap between the two.

Secondly, the log provides a useful record of actions/decisions taken to manage Risks, particularly the small number that require disproportionate management time. My weekly review helped me to update them while my memory was still fresh. This saved my neck a couple of times when a Risk became an Issue, somebody senior asked “why wasn’t I told about this sooner?” and I was very easily able to quote instances of escalating it at meetings or via email.

The other thing that having a Risk Log gives is an ID to use as an easy reference for filing emails etc. so I can easily find all related correspondence. If using Sharepoint or a similar filing system allowing Metadata, Risk ID can be used as a keyword for searching. When the project filing system is rather less sophisticated, I create a subfolder in the same location as the Risk Log to store supporting documents, appending the Risk ID as the first part of the file name e.g. ‘R-012_Escalation.msg’. It has saved a lot of time – by being very easy to put my hands on the key email to answer those ‘who did you tell and when?’ questions.

There is a difference between mechanically recording details in a Risk Log because our PMP says so, and making it work for us, but very little difference in effort needed to use it one way compared to the other.

Reference
(1) Mike Clayton, Risk Happens, Marshall Cavendish, 2011

Changing jobs after a long time at one place

Last year I changed jobs after about 15 years working for the same company. Starting somewhere new was more of a challenge than I expected.

At beginning of your career, it is common to hop from one role to the next every couple of years, and never really get immersed in one place for too long. (This was certainly my experience – I worked for five organisations in my first 12 years). In those roles, being relatively junior, you have a clear and focussed job to do based on your skill set. After a week or two of induction and finding bearings you can get straight on with your job and quickly find your stride.

Eventually you reach a point in life and career where a bit more stability is needed. By this time your career may also be reaching the point where advancement becomes more difficult, and you need meaty experience, which takes longer to attain. It also often coincides with greater demands from your private life – maybe by now with mortgage and family, security of employment becomes more important, or the convenience of being able to get home on time.
If I’m honest I was in one place for too long, although I had good reasons for staying as long as I did. I was ready to leave when suddenly the recession arrived in 2008 and good jobs dried up. As the market was starting to pick up again I had some clear internal career progression opportunities so I stayed put, and didn’t resume looking until my CV was bolstered a few years later.

I had forgotten how hard it is to start again, even as an experienced hire. Coping with a dramatic change in culture is expected and welcome – the challenge comes from no longer knowing how all the simple day-to-day stuff is done. Not “how” exactly, as the principles of project management remain constant, but the detail of the processes is different. The little nuances of the way things are written, or expectations around how ideas are socialised. Where to go to find out, who to ask.

At a personal level too, it is more of a challenge than I thought. There is a need to prove myself again, which creates its own pressures, sometimes self-imposed, after many years of having established a reputation. At my age I don’t want to run the risk of being let go too soon after starting; even after passing the six months’ probation stage I still felt anxious that I wasn’t yet doing myself justice. Last time I felt had to perform in this way I was still relatively early in my career and I was used to being in this position as a matter of course.

There are many positives too. I am able to bring in my experience of doing things a different way in my previous organisation or for my previous clients. It is refreshing to see where my new employer does things better. I have found myself assuring my more cynical colleagues that actually, things aren’t so bad here.

Above all though, I am glad I moved from a career perspective irrespective of the respective merits or otherwise of my former and new employer. From a personal standpoint it is very easy to become jaded and lose that little bit of spark at work when you have worked for the same company for a long time. I needed the refreshment provided by a new set of challenges. I recovered my enthusiasm for work, even maintaining it through quite a difficult first assignment. As the old saying says, “a change is as good as a rest”.

Radio silence

In the last three years a combination of family troubles (now all settled), difficult projects and a concerted and successful effort to change employer took up all my energy and spare time; a few posts were half-drafted and never completed.

I wonder how much benefit my thoughts and experience bring to other people (I hope so – a couple of the Use Case posts generate some traffic) – but I find that attempting to commit some thoughts to (e-)paper is personally beneficial as it makes me think in a more structured way about some of the things I am doing. I have no idea how some people find the time to post daily, about once a month is enough for me!

So here goes again…

Iterative planning

I previously wrote about how we combined elements of both Agile and Waterfall practices on a project to allow us to develop in an iterative way whilst remaining within the confines of our client’s Waterfall methodology.  In this post I want to look a bit more at how our iterative development approach was organised.

We planned the development into 3-week cycles.  Two weeks would have been too short to get some of the meatier components completed in a single iteration, and we would have had to break them up artificially.  Four weeks was too long and wouldn’t have given us enough flexibility.  We reviewed it as we went along and we always felt it was the right length.  On the other hand a 2- or 4-week cycle would have fitted better with the natural business cycle – which suited a regular drop in middle of the 4-week financial period.  The 3-week cycle worked well until we reached the go-live date when we needed to release code every 4 weeks and other issues briefly caused us to suspend our regular cycle (by then we had completed the core development anyway).  Three weeks would have worked well with a quarterly delivery cycle once things had settled down again into a regular pattern.

We adopted the agile principle of delivering a build on the deadline, and adjusting the scope to ensure it happened.  Within this, we to ensure that any build we provided was coherent and could process data from end-to-end, even if we couldn’t cover certain cases.  This meant that once we had covered off the minimum requirements, we were always able to deliver into production.

To ensure, outwardly at least, we appeared to be following a waterfall process, the development cycle included all technical specification updates alongside code changes, and all affected unit tests passed (we automated unit tests for new functionality but inherited manual testing for legacy code).

Business Analysts and Designers ran ahead of the development team so that there was a backlog scoped/designed to a sufficient level of detail, on a “just in time” basis so we didn’t waste too much time on low level detail until it looked like it might be in the next iteration or two.  They worked with the development team at the beginning of the cycle to make sure all requirements were fully defined.

The system test team also ran on the same 3-week cycle but two weeks in arrears, giving them up to two weeks to test the last build and then at least a week to prepare/update tests for the next release before it was delivered to them.  As we neared the intended release date we focussed on ensuring that code delivered to production was coherent.

The way each iteration cascaded into the next is more easily shown in a gantt chart:

System testing prioritised the most important functionality first. This meant that critical bug fixes identified in the initial round of system testing could be fitted in to the next iteration, because at that stage it was being worked on by the developers.  Non-critical bugs identified in testing would be added to the work queue and fixed in the next iteration if possible

Priorities for each iteration were set and revised jointly with the client, especially as the deadline drew nearer.  At each project meeting progress was discussed and changes to priorities noted so the team always had a clear view of what was likely to come next.

Ultimately this worked well; despite constantly shifting sands we completed our initial baseline on time and went live with a system containing all essential code from Day 1.

A few observations on PRINCE2

I recently attended a PRINCE2 Foundation and Practitioner course, and have offered some thoughts on my experience of it. Here are a few thoughts on PRINCE2 itself that struck me while I was thinking about my role as a Project Manager, in no particular order:

Not as inflexible as I thought. PRINCE2 has a reputation for rigid adherence to process and for generating lots of documents. Maybe that reputation was earned by earlier flavours of PRINCE2, for the current version allows flexibility and the manual has a section on tailoring. Where I thought my recent practices might not follow the PRINCE2 standard, I discussed them with the instructor who nearly always took the view that it was an acceptable use of tailoring.

Continuous Business Justification. My business users have been consistently poor at this through my career to date. As a rule they produce an initial Business Case produced to obtain funding but rarely revisit it between stages or when there is a significant change, unless more funding is required. They have been especially weak when dealing with change within a stage; some strange decisions are taken about functional changes when a quick benefits analysis would show that money could be better spent elsewhere.

Risks include Opportunities. The Risk Theme also includes the concept of Opportunity, defined as an uncertain event that could have a favourable impact on objectives. I can’t recall ever considering this aspect formally in a project, either as a supplier or on behalf of the client.

Lessons aren’t Learned. Like most people I have dutifully recorded lessons at the end of projects (and also as we go along) but what happens afterwards? In PRINCE2 the start of a project should include consideration of relevant Lessons Learned from previous projects. I haven’t seen this take place other than anecdotally based on the experience of the individuals involved. I’m sure I wouldn’t know how to go about finding applicable lessons within my own organisation, and I haven’t seen any evidence of it within the client organisations I have known well over the years. The other area where we could also do better is to review our own project performance more often, at the completion of key stages. Again, this is something that happens erratically, usually because we’re too busy to do it at the time.

Manage by Exception. A key principle of PRINCE2, to ensure management focus is where it needs to be. A tolerance (in time, money or both) is set for each work package, and as soon as it looks as if it might be exceeded the team leader responsible should raise it as an exception to his manager. This may not affect the overall project tolerance, in which case the manager need not take it further. Although my internal management tends to work on this basis, I can’t say that my client managers have adopted this principle very often, too much man-marking goes on….

One quibble. We don’t usually have a Quality Register (rightly?) As defined in PRINCE2 the Quality Register lists all checks that are planned, and as they take place is updated with the date and outcome of each quality check. Almost all the projects I have worked on over the years have carried out the checks themselves – which are planned properly (scheduled in the Project Plan and described in the Quality Plan), and results are duly recorded – but I don’t recall working on a project that had a central Quality Register. Dare I say it, but I think this is appropriate as I see a register adding little value but a lot of effort to maintain it. When I brought this up on the course it generated quite a bit of discussion. We thought there was probably a benefit in safety-critical projects (aviation, defence) but for normal work having an entry in the plan was sufficient.

A PM wears more than one hat. Is a supplier PM a PRINCE2 Project Manager, or a Team Manager? Of course, the answer is “it depends, …” Often, we might fill both roles simultaneously – as well as being a PM from a supplier perspective we are also the Team Manager from the Client’s perspective at the same time. This significantly alters the view we might take of what is required of us.

Overall, PRINCE2 provides a framework to use to save re-inventing the wheel; as a proven and widely recognised standard it can easily be sold to an organisation. As an experienced PM, I was pleased to find little that was new or that I don’t already do. My experience of the clients I have worked for over the years is that they are less methodical – perhaps that’s why they rely on external consultants so often.

Course review – PRINCE2 Foundation and Practitioner (QA)

I recently attended this week-long course run by QA. If you are thinking of attending it or a course like it, I hope that by sharing a few thoughts it may help you decide whether to attend it too. My view of the course is coloured by being an experienced Project Manager, so some of what I say may be less relevant if you are looking to move up into Project Management.

Why go?

My motivation for taking the course was simply to get a “tick in the box”. Many organisations expect it and I wanted to obtain the formal qualification as quickly and painlessly as possible. I had some prior experience of working on projects that were operating within a PRINCE2 framework (on an older version), but I knew I had gaps in my knowledge of the formal process and terminology.

The provider was determined by my employer – however I know that other training companies also offer similar courses and I expect they are not very different.

Course format and content

The course is very focussed on passing the exams, not learning PRINCE2, and should be judged accordingly! It assumes both some Project Management experience and that you have read the pre-learning material. It is split into two parts, covering each accreditation level, which can be taken independently of each other, although in fact all course delegates on my particular course stayed for the full week (as is usual). The first two days cover the Foundation level and the remaining three the Practitioner level, each ending with the official exam.

The format of each part of the week followed the same pattern. We were taken through each of the Themes and Processes in turn to the level of detail necessary to pass the exam, and then tried out a set of practice questions. The Foundation exam focusses more on the Themes, whereas the Practitioner exam looks at both Themes and Processes at the same level of detail. The good news is that the Practitioner exam is “open book”, which means that although there is more ground to cover, you only have to remember where to look for the detail in the official manual. The bad news is that each night (apart from after the Foundation exam on the Tuesday) there is homework to do, in the form of a second set of practice questions reinforcing the material covered during the day.

The middle of the week provided a welcome break when we all shared our own experiences of project management: where we felt our existing practice fell short of the PRINCE2 principles, or where adopting its practices might help us in future. We had some lively discussions.

My one real criticism of the course is that I didn’t like the format of the pre-learning. It was on-line only, so I couldn’t do it on the train, and annoyingly I had to wait for the voice to read out the words on the slides before being able to move on, which is one of my pet hates. I read a book (PRINCE2 Study Guide, by David Hinde) instead, which I had already bought before the official pre-reading came through, and which suited my learning style better – I recommend this book for anyone looking to study by themselves.

So, was it worth going?

If you want to gain the PRINCE2 as quickly as possible then – Yes. It would help if you have prior project management experience, but it isn’t essential.

If you are a relatively inexperienced Project Manager and are looking to study PRINCE2 from scratch as a way to learn project management, this is probably not the best way to do it.

With the benefit of hindsight I could probably have got away with just taking the exams after reading up, but actually I found the course useful as a refresher on good practice in general. The course’s cramming style suited me personally; it would have taken me a lot longer to cover the same ground in my spare time or one evening a week and I would have been more likely to forget some of the content by the time of the exam. I was very tired by the end of the week though!

How we did non-Agile Agile

From time to time there is a debate about Waterfall versus Agile development, and why one is superior to the other. In practice the situation where one or other clearly works best does not always occur in the real world, as I found recently while delivering a major project for a large infrastructure company. A regulatory change meant a new database was needed to accept a feed from a new data source, which resulted in significant changes to their existing billing system to allow it to read the new data.

The situation we started in, ordinarily, would have lent itself perfectly to Agile:

• At the outset, there was a large set of unknown requirements, but the uncertainty was around the detail – the big picture was clear;
• the priority of requirements was not known at the outset, and varied over time;
• the deadline (set by the regulator) was immoveable;
• we needed something in place early to test with externally sourced data;
• our team size was about right (8-10 for most of the project duration, although it peaked at 15);
• the core team had been working together for some time so an established team dynamic already existed.

But certain other factors ruled Agile out:

• lack of business user availability to work alongside the development team;
• a mandatory client waterfall methodology had to be followed, heavy in documentation;
• the client was genuinely scared of Agile, and it was officially out of the question. (The client had previously had its fingers burnt by an Agile project that had spent millions and delivered nothing).

As the programme manager put it, we couldn’t do waterfall because we would deliver a year late, and we couldn’t do Agile because it was forbidden.

So what do you do when you can’t use either approach?

We adopted a hybrid approach to gain some of the benefits of agile while remaining within the Waterfall constraints set by the client. Basically, we made it as agile as we could get away with while seeming (to the outside) to be following the approved methodology.

The client process defined certain deliverable documents at key points, before we could proceed to the next stage. The most critical ones were a requirements specification and a design document.

We were able to produce an adequate requirements specification as the high-level requirements were known, even though many of the key business rules were flagged as still being subject to agreement. It helped that many of the requirements were already met by the existing system, making the requirements appear more complete than they really were.

It then became a straightforward task to produce a high-level design document showing how all the requirements were going to be met, defining interfaces etc. Much of this design work would have been needed up front, even on a pure Agile project. It was clearly understood that the requirements (and therefore the design) would change during the course of development, so we would not have any difficulty presenting a substantially different final design document at project close if that turned out to be necessary.

Once the design was signed off, we adopted a different approach to the development phase. A series of short iterative waterfall cycles covered all stages from development to system test. A relentless focus on priorities ensured all essential functionality required from day 1 was completed first. We developed something as quickly as possible that worked, crudely at first, then adding more functionality with each iteration but allowing scope to vary as priorities changed. I will cover how we planned our development iterations in a further post. Finally as we approached the initial planned production release date, we reverted to a more recognisable waterfall cycle for final FAT and UAT.

We then planned further cycles after the deadline to deliver less critical functionality followed in subsequent deliveries every few months, following the same approach taking the next most urgent set of requirements in priority order. Not quite Waterfall, certainly not Agile – how about Nimble?