Posts Tagged ‘project management’

Risk Log – what should be in it?

February 27, 2018 Leave a comment

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Categories: Work Tags: ,

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

Conducting and Project Management

October 5, 2011 2 comments

Some more thoughts on similarities between conductors (recently, for me, this means choral) and IT Project Managers.

Strategy. The conductor shapes the whole piece as a performance by setting style and expression, and has a clear idea how he wants it to sound. (It is striking how performances of the same piece can be very different). In the same way, the PM sets out the strategy for the project and holds in mind a vision for how it is to be done.

Rehearsals / training. In many ways, the whole choral rehearsal process is a parallel to the repeated iterations of build-test-refine that any system undergoes before it is finally released. Rehearsing a choir is not just about teaching the notes, but also about how to sing together as a unit. As well as coaching individuals, a project manager ensures that the team knows how to work together – what the internal team processes are, who is expert in what, and so on.

Detail. While holding the whole piece together and the choir in time by keeping the beat steady, the conductor also brings in different parts at the right times, and indicates changes in tempo or expression. To do this he must have an intimate knowledge of how each individual part fits with the others to make up the whole piece. A PM uses his detailed understanding of the business background and of how all the various planned tasks fit together to decide which are the critical tasks to bring to the fore at different points during the project.

Constantly changing priority. I’m struck how my current choirmaster will sometimes sing along with a part when it falters for a little while until it is secure again. Perhaps at that point he may not pay attention to some of the other parts at all. I once sang in a concert where the conductor never brought my part in at all, because he knew he could safely ignore us. This is very much the way a PM will focus on a hot issue until it is resolved maybe to the exclusion of other things for a short while. And of course the choirmaster can only sing one part at once, just as at any point in time at work we can do only one thing at a time.

Contribution of team members themselves. In an ensemble, listening to each other is critical, to keep together – in time, in tune, and expression. In a project this means discussing issues, being aware of what colleagues are doing and chipping in sometimes when needed. The PM should encourage an environment that enables this to happen.

Finally, both have ultimate authority – there may be some discussion at first but ultimately what you say, goes, and there is nobody else to stop you. Which means you need to get it right!

Categories: Work Tags:

Making progress when the business won’t

January 31, 2011 Leave a comment

Successful IT projects demand commitment from the business customer. But what do we do if they are committed enough to find (say) £5m for a new system, but not committed enough to free up any resources to be involved?

This has been a recurring issue for me over the years, including a recent project which was very cross-functional with no single clear business owner. Despite a legal requirement to meet a clear deadline which all parties agreed must be met, at one point deadlock was reached when every stakeholder involved agreed that it was somebody else’s responsibility, and nobody within the business was prepared to drive progress forwards. So at times there was a lot of drift, and no decisions.

We found ourselves facing an immovable deadline and a large degree of uncertainty about the requirements. Ordinarily this might be a good candidate for using an agile approach to development, but in our case we didn’t have the commitment from the business, so we had to try to fill the gap ourselves. We have found that the following approach works

  • Subject Matter Expertise. Understand the subject matter well – preferably better than the business themselves. Then most of the decisions will be the same as the ones that the business would make. (But not all of them).
  • Propose solutions for ratification, don’t ask. If you ask what the requirements should be, it will take months to get a decision. We couldn’t afford to wait – offer up something for a yes/no decision. But expect sometimes that the answer will be no.
  • Make lots of Assumptions. Compile a large assumptions list as a basis to get started, and verify as you go along.
  • Good documentation. This is a must so you don’t lose track of where you are as priorities change. This doesn’t apply just to requirements documents, also to design and code baselines.

There are also some dangers. We made some mistakes when our assumptions were wrong, resulting in some wasted effort. Some early design decisions turned out to be sub-optimal, when the rationale was undermined by a later emerging requirement. However, had we waited until we had a perfect set of requirements we would have delivered months late. There is also a risk that what inevitably becomes an IT-led solution doesn’t meet with widespread acceptance from the end users (but if they were largely excluded from the process, what do they – or their managers – expect?)

To stand a chance of success, this needs a good team with extensive business knowledge, which can’t be acquired overnight (so an established core team needs to be in place already). Luckily we were able to retain the core team from a related project in the same area. It also takes a lot of effort to manage all the business stakeholders; in our case this was the Programme Manager’s role, leaving the IT Project Manager to face inwards to the team and other IT stakeholders.

Of course this doesn’t stop somebody coming up with a completely new requirement only a few weeks before the Go-Live date…

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