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

The intervention of real life

September 11, 2013 Comments off

A year has passed since my last post.

This was not intentional, but was a reflection of an extremely busy period at work combined with family problems which together used up all my spare time. Both have now come to an end and I have some material in preparation.

Categories: Personal

East of Bloomsbury, Part 5: Regent and Argyle Squares

August 23, 2012 Leave a comment

This is the fifth part of a walking tour following a Pevsner Perambulation in part of Bloomsbury, London; the previous part is here. See the introduction for fuller details; page references are to the Pevsner Buildings of England series volume London 4: North.

Regent Square

Regent Square

We start at Regent Square, entering the gardens in the centre.
The large terrace on the south side (Nos 1-17) is the only one remaining from the original development of the square in around 1829. The last three to the left are set slightly forward and are all that remains of the original houses in Sidmouth St (Nos 51-55).

51-55 Sidmouth St

51-55 Sidmouth St

United Reformed Church, Regent Sq

United Reformed Church, Regent Sq

To the right is the United Reformed Church (originally Presbyterian), which now goes by the trendy name of Lumen. The complex occupies the corner with Wakefield Street. This is a outwardly plain brick modern building of 1965 replacing its bomb-damaged Victorian Gothic predecessor; judging from pictures this was a major wartime loss.

Regent Square, NW corner

Regent Square, NW corner

Turning around to view the opposite (north) side of the square we see postwar redevelopment. To the left and in front of us are former LCC flats of c. 1958, and at the right hand end is the more modern St Peter’s Court. As its name suggests it replaced a redundant church of the same name (originally by the Inwoods of 1820s, with Greek portico similar in style to St Pancras by the same builders and damaged during the war). Notices in the square give an account of some of its history and residents.

Regent Square, NE corner

Regent Square, NE corner

Holy Cross church

Holy Cross church, Cromer St

We leave Regent Square by the NW corner between the LCC flats which brings us through to Cromer Street beside Holy Cross church. This brick towerless building was built in the Early English style in 1887 by Joseph Peacock (see p255) and is hard to photograph in summer! I have never found it open except for services.

Cromer Street, White Heather House

Cromer Street, White Heather House

We turn right on Cromer Street and go along as far as necessary to look at the flats on both sides of the road, which show the development of council housing from the thirties to the fifties. The first few blocks on the left hand (North) side are early St Pancras Borough Council housing dating from either side of the war, White Heather House serving as an example. By contrast the right hand side consists of nine blocks of flats placed at right angles to the street built 1949-51 and refurbished 1996 so they look newer than they are. Four more are on the north side.

Cromer Street, S side

Cromer Street, South side

Tankerton Street

Tankerton Street

We now retrace our steps along Cromer Street to look at some earlier public housing erected by the East End Dwellings Company. The streets on the right are each filled by single developments of flats which although cramped must have been a vast improvement on what they replaced. Tankerton Street, of 1893, is an example (2nd street on the Right).

Tonbridge House, Tonbridge Street

Tonbridge House, Tonbridge Street

We continue to Tonbridge St (opposite Holy Cross church) which we turn into. Tonbridge House on the left hand side is slightly newer (1904) and more spacious, having been built by the LCC. The original sign remains.

Tonbridge House sign

Sign on Tonbridge House, Tonbridge Street

Argyle School

Argyle School, Tonbridge Street

Continuing along Tonbridge Street, Argyle School (see p.263) a little further along on the right hand side, a good example of a Board school slightly hidden from the road by a brick wall.

Argyle Street

Argyle Street

We turn right just before the school and cut through the alleyway into Argyle Street. This is the most complete of a block of a few streets centred around Argyle Square developed in the 1820s, in this case from 1826.

We continue straight on in Argyle Square itself on the left, which has terraces on three sides (many of them now hotels) and a small garden and a basketball court in the centre. This was developed slightly later than the surrounding streets, in the 1840s.

Argyle Square

Argyle Square

Crestfield Street

Crestfield Street

The other streets are more mixed, with original terraces interspersed with newer infill. Crestfield Street and Birkenhead Street both date from 1826 extend the long sides of the square the north (the left as we approach) and St Chad’s Street (from 1827 onwards), forms the continuation of the north side.

Birkenhead Street

Birkenhead Street

St Chad's Street

St Chad’s Street

We continue along St Chad’s Street to the main road at the end, which is Gray’s Inn Road and where the next section of the tour continues.

A further post will continue the tour.

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