Archive

Archive for the ‘Work’ Category

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: ,

A few observations on PRINCE2

December 30, 2013 Comments off

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.

Categories: Work Tags: ,

Course review – PRINCE2 Foundation and Practitioner (QA)

November 28, 2013 2 comments

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!

Categories: Work Tags: , ,

How we did non-Agile Agile

September 13, 2013 Leave a comment

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?

Categories: Work

Thoughts from the beach

June 7, 2012 Leave a comment

I recently returned from a break of over two weeks off work, which included a 10 day holiday in Barbados. This came at the right time, following a very intense period on my current project which has been full-on since Christmas. I returned to work refreshed, and relieved to find my deputy summarising events by saying “you’ll find a lot of emails about a lot of things, but basically, the last one says, ‘Thanks.'” Naturally as I return my break has given me some fresh perspective and a few observations.

Time to switch off is important; I didn’t realise how stressed I was until I discovered how relaxed I had become. I think it’s important with a stressful job to have a two-week break because it always takes me a couple of days to forget about work including all the things I forgot to do before I left. Then two or three days before going back to work I start to think about it again. By taking over two weeks it meant I forgot about work altogether for at least ten days – a break of just a week means I hardly turn off. I’m sure I’m not alone in being like this (I know others who say the same). On this occasion, immediately before going away we attended a big social event, which really helped to get work out of my system straight away and I started my holiday proper with a clear mind.

As the holiday drew to an end, and on the overnight flight (I can never sleep on planes), my thoughts naturally started to return to the work facing me on my return. When I’m in the middle of the daily routine I normally find I’m so busy dealing with all the immediate tasks in hand that I never have the chance to look beyond the immediate to the longer term. Too often urgent tasks crowd out the important but less important. I don’t spend enough time thinking strategically – what do I need to do now to make things better in 3-6 months? Never mind anything longer term than that. Being away from work allowed me to think about these things, and act on my return to bring some of it about before the moment was lost.

The other thing a period of leave gives me is a chance to reassess my own work. Again, this doesn’t happen enough at work because I’m too busy. Some things I need to do personally – push back more with some of the random requests I get from management. Also I need to offload some more tasks to others as I’m just too busy in general. Luckily I can do that at the moment as I have some capable people who can take some of these things on – which isn’t always the case.

A couple of side notes: firstly I couldn’t believe how many people took laptops on holiday – it’s the last thing I want!

Secondly I noticed that the waiting staff at the hotel restaurant addressed their manager as “Sir”. At the team meeting following my return I suggested this might be something we should consider copying, but the rest of my team were of a different opinion!

Some other views:

The Case for Vacations – Emily Pines, The Energy Project

The Importance of Vacations, for Stress Relief, Productivity and Health – Elizabeth Scott

The Importance of Taking a Vacation – Mary Abbajay

Take Vacation The Journey, April 2011

Testing approach notes

March 27, 2012 Leave a comment

Recently I delivered a project where testing was severely impacted due to the difficulty of setting up test environments in time.

The client has a detailed test policy setting out all the stages of testing that must be undertaken and when. It follows a classic ‘V’ Model, in practice we have four main stages of testing each carried out in its own environment

  • Unit test by developer
  • System Test to prove functionality
  • FAT/UAT with realistic volumes of data
  • Operational Acceptance and Pre-Production testing to prove build and performance in an environment that is supposed to match production

The full set of environments for our main development phase was not provided in time. Eventually the situation stabilised with the FAT/UAT one missing so we had to use the Pre-Production environment for that purpose, as it was the only environment large enough to test with realistic volumes of data copied over from the Live system.

As a result we were never able to do the final set of testing which led to a number of issues on release particularly:

  • the Production environment required some configuration settings that were not needed in any of the test environments
  • stricter permissions on Production meant we couldn’t run some of the migration scripts without modification
  • we couldn’t rehearse the release as it was intended to be run, so instructions had minor errors leading to confusion e.g. where we’d merged test releases into a single production release

One of the key lessons learned from earlier development phases was that having a chance to do a dry run of the release was invaluable in identifying missing, inaccurate or ambiguous steps in the instructions. It was a retrograde step and led to complaints about “Failed Releases” from other client managers in roles like “Service Delivery”, all demanding absolute perfection. Consequently both the client PM and I had to expend too much effort trying to set expectations and dealing with the inevitable political fallout, which was largely out of proportion as in fact all the application code ran perfectly because we had been able to test it adequately.

Having said that, setting high expectations about the ease of implementing a release is a good thing. In previous roles I have been the gatekeeper – it is hard enough keeping production systems running uninterruptedly just due to the vagaries of hardware and operating system software. Past experience tells everyone that introducing application software upgrades almost never runs smoothly. As well as the application in question, there are impacts on shared infrastructure or dependent systems to consider. It is not surprising that the default position of the people running the infrastructure is to deny any change and accept it only when absolutely necessary. This is especially true when there has been a past history of failure.

The benefits of this approach are clear – to minimise the risk of any system downtime, either due to a botched release or subsequent poor performance bringing the system (or others) to a halt.

On the other hand, setting a very high bar for every system change in all systems is expensive incurring additional costs by

  • providing infrastructure for additional test environments and managing it – which gets ever more expensive as the production specification is reproduced more closely.
  • carrying out an extra round of testing, setting up the environment and the data, and testing the installation process and carrying out a regression test as a minimum. This environment might only be used for one week every three months.
  • lengthening the project duration to fit this extra step in.

Is it worth it? The impact of system outage needs to be assessed.

Some applications demand high availability, where any downtime has an immediate and measurable cost to the business e.g. banking systems or online retailers. There is also the cost to a company’s reputation if a service is unavailable or perceived as unreliable.

For less critical systems, the case is less clear cut; it may actually be more cost-effective to dispense with the final round of testing and then deal with any subsequent issues as they arise. In our case, the system is business-critical but in fact t needs to be fully available only once per week – on any other day the business can cope with a half day outage or more once the main processing overnight has completed. Knowing this, we always schedule releases for the day after to give us time to deal with any issues before the next week-end – by then issues remaining are likely to be irritants rather than critical. It is much cheaper for a support analyst to spend half a day with a developer to fix any odd issues with the release as they arise. From a commercial perspective this is even more so if the developer’s time is covered by a Fixed Price contract and paid for anyway.

All this needs to be considered at the start of the project when the test strategy is being agreed; in my experience this isn’t done often enough.

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.