Posts Tagged ‘planning’

Iterative planning

April 22, 2014 Leave a comment

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:

iterative gantt

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.

Categories: Work Tags: ,

Lessons Learned from a successful catch-up

January 16, 2012 Leave a comment

I previously noted some lessons learned from issues encountered during releases on my last project. To redress the balance I am now going to make some observations of an aspect that went well – a managed data catch-up following implementation.

The project included setting up a service to collect and collate customer usage data, before passing it on to my client’s billing system. The usage data was to be supplied by each customer on a daily basis via an agreed interface, but before go-live each customer had technical or data collection problems which meant that none was ready in time. Rather than postpone the start altogether, we agreed to let the customers to collect their data and store locally for a couple of months and submit it late in a controlled way. This managed catch-up was planned and executed very well.

Contingencies and scenarios. Once the possibility of a delayed start arose, we held a planning session to identify all the combinations of factors that had to be considered. For example, what if each of three separate systems involved was not available in time? What if it spanned more than one financial period? How long a delay could we absorb before catching up became unfeasible?

Clear steps. Once the likely scenario became clear, we defined a set of very clear steps to follow, including anticipated error scenarios. This was important as processing depended on everything running in the correct sequence. We verified the steps on a test environment – the chance to rehearse is something I am keen on to improve the chances of success. We minimised the risk to the production system by starting with a small volume of and gradually building up the volumes after that once we were confident everything was running smoothly.

Active Monitoring. As well as running the manual steps, every day we actively checked that automatic processes had completed successfully by querying the data rather than relying on error logging (in case of bugs).

Daily progress call. There were five separate groups of people involved – the business, development project, customers’ IT technical teams and two support teams (one for each main application). Each day we held a conference call with all parties to confirm progress, resolve any issues and to agree next steps.

Dedicated co-ordinator. One of the team took responsibility to oversee the process and make sure everything happened as planned. He was also the single point of contact for any issues, leading to clear communication. While activities were being carried out he made sure all interested parties were kept in the loop via email.

Management status updates. Senior management were kept informed of significant progress via email, usually following the conference call, and when to expect the next update. The project was high profile and this proactivity reassured management that everything was under control.

Overall the catchup worked very well – the sole error was when the regular person in one team was on holiday and his replacement didn’t follow the steps correctly. Otherwise, everything ran smoothly, all issues encountered had been foreseen and we caught up ahead of plan.

It only took nine years…

August 5, 2011 Leave a comment

Tomorrow, the English Football League season kicks off. At 12:45, the team I support, AFC Wimbledon, resumes what its supporters see as its rightful place only 9 years after the spineless decision to allow Milton Keynes to steal Wimbledon’s football team.

Back then a group of the fans, suddenly without a team to support, decided to do something about it and started a team from scratch playing at the lowest level of senior football. The aim was to get back into the Football League in ten seasons, and in fact it took only nine. Anyone needing a successful project team knows where to look!

Putting aside the logistics of finding a ground, assembling a team and putting together a realistic long-term business plan, as I plan to start a new project myself I have been reflecting on the timescales and the contingency.

Projects often have a must-hit delivery date. Plans never run perfectly, so part of the planning process is to include some extra time as a contingency for the risks that may have an impact on the plan. Unfortunately this is often the first casualty of a management-led review of the plan – or a delay at the beginning uses it all up straight away.

I expect the initial goal of “back in the league in 10 years” was plucked out of thin air over a pint in the first day or so. It has a ring about it but was essentially arbitrary. But then so are so many of the implementation dates in more mundane projects – what is so special about January 1, or April 1?

Having picked a date, some analysis follows – how achievable is it? Surely with AFC Wimbledon’s large support and money it ought to be able to buy better players than the other teams and win every year? That would be Roman Abramovich’s approach, up in 4 years, no problem.

The other guide is precedent from similar projects. In modern times, no team had started from nothing and got into the league. The nearest case was Aldershot who had gone bankrupt 10 years before and had been reformed, like AFCW, but had the advantage of retaining a ground and their existing youth team which formed the nucleus of their first squad. Even with those advantages, 10 years later, they were still in the Football Conference, one level below the league (they eventually did it in 15). On the plus side, AFCW could count on a larger core support which meant more income, but no more than other recent ex-League teams of similar standing in the Conference.

But there were lots of other unknown factors – you can’t just get a bunch of players in and expect them to settle straight away, however good, even at the bottom of the pyramid. This proved to be true in the first season as the team lost a few games early in the season before the squad settled, costing promotion that year. And later in successive seasons they failed to be promoted by losing playoffs.

You also have to allow for the unexpected – the FA inserted an extra level in the pyramid at the end of season 2. A 10 year plan allowed enough time to absorb this – 4 promotions to go in the next 8 years didn’t look too daunting but 4 in 6 would have been unlikely.

Too often in my working career management have insisted on a timescale that assumes the equivalent of four promotions in four years. When the unexpected has come along – the equivalent of inserting another level in the pyramid – the same management are then surprised that the project misses its target.

In retrospect – and at the time – the original 10 year plan felt realistic, as it assumed promotion in alternative seasons but also that the team would get stuck at one level (as happened to Aldershot), probably the Conference. This turned out to be a good estimate, which with a bit of luck along the way, was beaten.

Categories: Work Tags: , , ,

Where the time goes: monthly admin

December 29, 2010 Leave a comment

I have recently been planning a new phase of work, and one of the issues I had to consider was how much work (if any) I could assign to myself. So I have been doing some analysis of how I actually spend my time, compared to what is in the project plan.

After email, the next big killer of time is the weekly and monthly status reporting cycle. As a development project for a consultancy firm, this comes in two separate streams of work; weekly status meetings and updates for the client, and monthly project reporting to my management. On top of that there are some routine administrative tasks that have to be carried out each month.

Weekly status reporting

I have two separate weekly meetings, one with my own project team, and a wider client project team meeting. Both take at least an hour, and also I always need some preparation time for my own team meeting and to send out minutes at the end, which usually means 4 hours per week for both.

I have to provide a weekly report to the client PM; this is very simple and takes only about half an hour, additionally I need to keep the plan up to date, review risks/issues and if I keep on top of it I can do that in an hour.

The other thing I have to do weekly is complete a timesheet recording how I have spent my time, to justify to the client how they are spending their money (if it is a time and materials contract) which takes me a few minutes a day if I record it as I go along, so perhaps 30 minutes per week.

This is a total of 6 hours per week.

Monthly status reporting

Monthly reporting is aimed at my management, written reports around month end followed by a review meeting a week or so later.

I have to write a monthly status report, which although not too arduous involves reviewing and updating quite a lengthy document due to the size of my project historically. This usually takes about an hour and a half. More importantly, I have to complete a financial report; luckily most of the work is done for me (when I used to do it in the past it used to take me a couple of days spread through the month) so all I have to do is check it and deal with any discrepancies and anomalies, and this takes me about two hours.

Finally there is the review meeting itself; with preparation this takes me about an hour and a half. Of course I usually get some actions following the meeting, and I’m not even counting the time spent on those.

That’s 5 hours per month altogether.

Company administration

There are a number of personal or project-related admin tasks that I have to do throughout the month.

Of these the most significant is raising invoices, which can be time-consuming to ensure it is correct and requires reconciliation against timesheets and leave bookings to make sure they are all in line. Surprisingly this takes 2.5 hours, even though someone else actually does some of the routine work.

Then there are the other bits of routine administration that can pop up any time but especially around month end – approval of other people’s expenses and overtime, leave requests, payment of invoices. None of this takes very long, but it still takes a few minutes to log on to the right system and press a button, perhaps an hour in total.

Finally there is personal administration, which again tends to follow a monthly cycle. This involves entering time and expenses into separate systems. Surprisingly, the most time-consuming task is dealing with mobile phone expenses, as it has to be itemised between work and personal use, and is more time-consuming than it might be. Altogether this works out at 1.5 hours per month. Of course my employer seems to think that I should do all this on my own time!

So that all takes about 5 hours per month


At an average of 6 hours per week, and 10 hours per month, that means that 34 hours per month is taken up with routine reporting and paperwork; as close to a week as makes no difference. As I also worked out in an earlier post that just processing email took a further 6 hours per week, in practice this means (at best) I have only 3 working days per week for more productive work.

I have worked on some projects where routine reporting and paperwork took up a much higher proportion of my time. I think that my current weekly and monthly overhead is about as low as it can be, and could easily double. The only way I can reduce the amount of time I spend on things like this is by finding a project administrator to take over some of the remaining routine tasks.

Categories: Work Tags: , ,

Where the time goes: email

October 28, 2010 1 comment

I have recently been planning a new phase of work, and one of the issues I had to consider was how much work (if any) I could assign to myself. So I have been doing some analysis of how I actually spend my time, compared to what is in the project plan.

One of the big time-consumers is keeping on top of email. So for a random week I tracked the number of emails I sent and received, and the time I spent each day processing them.

I normally process email daily. I set aside a specific time to deal with it and ignore it for the rest of the day, unless I have a spare 10 minutes or so. I try to read and respond to everything that can be dealt with easily more or less straight away. If a more considered response is needed I add it to my ‘To Do’ list and prioritise it alongside everything else.

I have defined the time to process the email as including the time taken to deal with it following my normal routine, but excluding any response that required prolonged effort. For example during this particular week, there was an issue that required two emails, taking an hour and a half to write by the time I had checked my facts, thought about it and chosen the right words. I haven’t included this time as “processing” email.

I have counted all genuine emails including staff circulars (which I am expected to read and act on if necessary), but not auto-generated system emails like those reminding me that it’s month end.

That works out as 6 hours, in practice nearly a full working day per week, as follows:

Day Emails received Emails sent Minutes to process
Monday 19 12 70
Tuesday 17 11 75
Wednesday 13 7 80
Thursday 18 11 75
Friday 19 9 60
Total 86 50 360
Average 17 10 72

Was this week typical? My gut feeling is that if it isn’t, it underestimates the time slightly. On the Wednesday I had a half-day meeting, which also involved most of the people who tend to send me emails, reducing the number that day.

What about the others in my team? I’d guess they probably all receive slightly less than me; we don’t tend to email each other too much within the team

How does this compare with other projects? I have certainly worked on some projects where emails were far more common. I remember one job I had where I was getting 40-50 per day. I have had times when I have had less email, but only in non-Project Management roles.

It would also be interesting to know if the slightly over 4 minutes per email received is a good rule of thumb to use, if in a different environment I find I have much more (or less) email. If so it would mean someone receiving 100 emails per day would have time for little else – remembering that some of them would need time and thought before responding.

One thing’s for sure, my project plan doesn’t include any time for processing email!

Categories: Work Tags: ,

An alternative New Year

September 23, 2010 Leave a comment

I’m sure I’m not alone in finding the arrival of September comes with a feeling of foreboding. For years I couldn’t quite understand why, then I realised that it was a throwback to my schooldays (which I hated) – the autumnal nip and the damper air recalls the feeling of dismay that used to mark the end of six weeks of freedom and a return to the semi-imprisonment of school. Despite the passage of 25 years I still feel a slight frisson of something looming…

And yet, and yet… The change of air arouses another feeling, a sense that now is time for something new. Going back to school used to mark the start of a new set of challenges for the year ahead, with the slate wiped clean and a chance to get off to a good start for the new year.

Even in the world of work, the start of the academic year still designates a time for change – how many new projects start in September? Indeed, I’m looking to ramp up my team to cover a new phase of work right now. Looking back I realise that three of my five jobs started in early autumn, and a fourth would also have started then if I hadn’t been required to work the whole of an extended notice period. It’s more than just coincidence that each of those employers was recruiting to fill a vacancy to start in September.

In many ways this is a natural time for a fresh start. During the summer period (really any time from late May onwards) work continues pretty much as it has done all year, except that most of the time the team is below strength due to annual leave. Many European countries often effectively have a national closedown period when most organisations are on a skeleton staff and any interaction with them has to wait until their staff return. Although in the UK we try to keep operating normally throughout the summer holiday season, inevitably people with families are off work for much of the time in late July and August (and those without often just before or after those times) there is still some disruption and a tendency to defer making wholesale changes.

By September, most people are back at work and teams are at full strength again. There is also a good three-month window to make progress before things start to slow down again in the approach to Christmas. Initiatives that have been held over are now put into practice – I have noticed that I have received a lot more announcements and instructions to comply with various requests in the last couple of weeks than during July and August.

Personally, it is also a good time to get something done. Returning refreshed after a holiday, now is a good time to act on resolutions that follow from some reflection while away. I feel much more inclined to tackle new or difficult work now, or set about a change to my routine, than I do when I come back to work after the Christmas/New Year break. Maybe it’s also something to do with it being the middle of winter, dark both when I go to work and when I leave for home. I always feel much more motivated in bright sunlight, which we still have at this time of year, than while suffering from January blues.

Why wait for January 1 to make New Year’s resolutions? Make them now!

Categories: Work Tags:

In a Nutshell: Five Principles of Project Management

September 9, 2010 Leave a comment

Glenn Alleman (Herding Cats) has recently suggested Five Immutable Principles of Project Management, five questions without which your project is almost certainly doomed to failure

His five principles are:

  1. Know where you are going by defining “done” at some point in the future.

  2. Have some kind of plan to get to where you are going.

  3. Understand the resources needed to execute the plan.

  4. Identify the impediments to progress along the way to the destination.

  5. Have some way to measure your planned progress, not just your progress.

There is no real magic to Project Management other than trying to keep one step ahead of all the forces that can come along to trip everyone up. I agree with his summary – if you focus on these five, that’s the bulk of the work done.

To get a definition of “done”, you need to define the scope (requirements). Scope management takes up a lot of time, not just at the beginning but also especially during the busy period in the middle when there has been time for the business to change its mind, and as the detail is uncovered. This is rightly top of the list; not only does it come first sequentially, but without it you can’t do the rest.

Planning means much more than just an MS Project gantt chart of tasks and dependencies – how we are going to achieve our target. I have worked on several projects where the Project Manager (not me!) maintained a plan in MS Project, meticulously, tracking our failure perfectly.

I would swap 3 and 4 in the list, as once you have a plan you also have to identify all the Risks and Issues that need to be addressed (straight away, usually). It’s also about getting obstructions out of the way in time so the team can keep working, or having a Plan B (and Plan C…) if you can’t.

Resources doesn’t just mean effort, but also what kind of people you need, and making sure you have the right equipment – not just hardware but the banal like offices and desks for the team. Producing good estimates is a black art and the subject of many books, but however you do it you need a benchmark to refine as you go along. Measuring progress is just as elusive, as developers, especially, are always overoptimistic, and can often cheerfully report a 90% complete status for days on end. I prefer to report either on the basis of 0 or 100% done, and break the tasks down to a low enough level of granularity to be able to add up the completed tasks as a percentage of the total.

Of course, as well as the project as a whole, you can ask the same questions of each task.

I think back to all the failed projects I’ve worked on, and (as I’ve commented before) the main contributory factor of almost all of them was that right from the beginning, we never had the scope or the requirements set down clearly and correctly. This meant we started off badly, and never recovered. Define “done” and you are halfway there.

Categories: Work Tags: ,