Archive

Author Archive

Risk Log – time consuming red tape?

September 26, 2017 Leave a comment

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

Advertisements
Categories: Work Tags:

Changing jobs after a long time at one place

August 26, 2017 Leave a comment

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”.

Categories: Personal, Work Tags:

Radio silence

August 25, 2017 Leave a comment

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…

Categories: Personal

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