Requirements part 5 - a very useful spreadsheet

I think there might actually have been one or two more posts on requirements than 5. No matter the end of the tunnel is in sight.

I've written quite a bit about what not to do with requirements and conversely some useful salves for common problems. What I haven't done (until today) is state clearly my approach to managing requirements (and more besides) or provide the tool to get the job done.

To date, we've talked about MoSCoW analysis (yuk!), pair-wise comparison, cost of compliance / non-compliance, KANO analysis and quite a bit more besides. We've never talked about UML or a bunch of other stuff, but ultimately (as you'll see) that might not matter too much.

Consider the illustration below - a veritable soup of inputs relating to requirements. Equally, a customisable and completely transparent score card that can be constructed and agreed by stakeholders early in the process.

What we're starting to get towards here is an approach to requirements prioritisation and management that can be highly customised to suit any situation. 

Get the stakeholder buy-in right, get the score card right and the rest will follow.

In the example below, I've used the following scoring elements - you however can use what you like.

• MoSCow - exactly what it says on the tin. MoSCow does have its place albeit do remain cognisant of the limitations previously discussed.
• Kano - see last post. A quick and easy way of assessing non-monetary value
• Contribution to the business plan - if it doesn't contribute, should you be doing it?
• Compliance - do we have to have this to meet regulatory requirements?
• Senior stakeholder flag - if the the budget holder wants it in taupe, then let's have that right out in the open from the get go.

Your score card might incorporate the elements illustrated above or be something complete different. You might have specific organisational imperatives which mean you incorporate none of the elements above - fine. The approach is no less valid.

So - you've got a score card - what next? Excel that's what. What you're seeing below is the scorecard above incorporated into Excel.

It's not too busy a spreadsheet but it has got a couple of tricks up its sleeve.

First, the fields are 'constrained' and aligned with the scorecard.

And, we've got a a simple but long formula to do the scoring calculation. Note the red highlight. We don't put the scoring in the formula itself - we use a lookup to a table elsewhere. This is important and we'll discuss this more later.

=IF(C2="Must have",Lookups!$B$1,(IF(C2="Should have",Lookups!$B$2,(IF(C2="Could have",Lookups!$B$3,(IF(C2="Won't have",Lookups!$B$4)))))))+IF(D2="Dis-satisfier",Lookups!$D$1,(IF(D2="Satisfier",Lookups!$D$2,(IF(D2="Delighter",Lookups!$D$3)))))+IF(E2="Key",Lookups!$F$1,(IF(E2="Required",Lookups!$F$2,(IF(E2="Aligned",Lookups!$F$3)))))+IF(F2="Yes",Lookups!$H$1,(IF(F2="No",Lookups!$H$2)))+(IF(G2="Yes",Lookups!$J$1,(IF(G2="No",Lookups!$J$2))))

I've uploaded the spread sheet here and you can play to your heart's content.

Some things to bear in mind.

1. You aren't constrained to 'sum' the scores. Multiplication has its place particularly as it opens up using a zero to effective nullify a requirement
2. You aren't constrained to using this just for requirements - the same approach works very well for (say) assigning a risk rating to server moves in a data centre migration
3. I've used significantly larger spreads sheets both in terms of the number of criteria used and the scores which correspond to those criteria. Undoubtedly there's a limit but I haven't found it. If you do (and good luck with that) you can always split the formula in two and sum the output.
4. Don't limit yourself to linear scoring - in point of fact, you're going to need to justify very carefully the use of linear scoring (i.e 1,2,3,4,5,6 as opposed to 1,3,8,20). Most things (I think) will benefit from a non-linear scoring approach.
5. Make sure you get your criteria right from the get go, the scoring only needs to be 'about' right as we re-tune that later on.
6. Weighting - don't think you can't apply a specific weighting to one or more elements on the scorecard - in point of fact this is just another way of playing with the scoring but don't rule it out.
7. If you're smart enough you can probably use a custom list in SharePoint to do this.

Finally, getting the scoring in the scorecard right from the get go is tough. So tough in fact that I discourage you from trying. Stakeholders can get a bit cagey too as, while they see the merit in the approach, they tend to be less certain about getting tied down by a scorecard that they (quite understandably) can't appreciate the fullest implications of at the outset.

Fine tuning the scoring is the subject of the next post.

Requirements part 4 - Kano Analysis

One of the things that I always keep in my mind when assessing and prioritising requirements is the cost of fulfilling the requirement relative to the cost of not fulfilling the requirement. I tend to think of this as the cost of compliance versus the cost of non-compliance.

Cost is an important dimension to incorporate into the overall requirements management effort, stakeholder engagement activities and so on and so forth. The application of this sort of approach is broad. I've recently been working with a client to work out which of their 'extensive' software library they wish to retain and which they can afford to withdraw. 

It isn't quite the case that there's a one to one relationship between a software application and a set of requirements. But there is often a 'service' comprising of one or more applications (and possibly more besides) which together fulfil a set of business requirements.

With all of this said, costs of compliance / non-compliance, serve as a useful entry point to start a conversation about 'what's in, and what's out'. It's quite useful too to bring any written business objectives into the equation as well.

But, as I say above, the cost argument is an important dimension, it isn't the whole story.

It can be difficult to sell a decision based wholly on cost (even if the decision is actually wholly cost based). This can be particularly trying when the end-user is divorced from the costs. So, we can bring something else into the equation which can help namely, Kano Analysis.

Kano analysis nicely skewers the fact that there are some very different types of requirements as far as stakeholder perception goes.

1. If you walk into a room and turn the light on, and it comes on you're only ever going to be so happy. On the other hand, if the light doesn't come on you will be dis-satisfied.
2. If you walk into a room and the temperature is too cold, but you can adjust the temperature with a thermostat, you'll probably be satisfied.
3. If you walk into a room and there's coffee and biscuits laid out for you, you'll probably be delighted.

Kano analysis is intended to give you a structured approach to identifying which category your requirements fall into with your stakeholders. It has the added bonus of being very quick and easy.

See the illustration below. All we need to know is the answer to two questions - the answers need to represent a consensus of the stakeholders. Workshops can be used to elicit the information and you could do something useful in a room of people with sticky labels (I'm all for getting decisions made at the coal face)

With these two questions answered we can map a requirement to one of the following categories. In practice, you don't tend to get any of the combinations marked null. It does happen an usually it's because there's a lack of consensus or clarity.

We can usefully articulate the requirements as follows. I haven't bent my meagre brain to it yet, but I can see a useful bubble chart in Excel mapping out the requirements - do let me know if you beat me to it.

And, in the event that ultimately all decision making is cost led, you can engage and communicate with stakeholders to manage expectations (and sometimes fallout) from commercial decisions that have implications for them. It's all good, useful information.

We've got two last bits to cover off and then I think that'll be an opportune point to take a break from requirements.

More on forecasting

Before going on too much further let's discuss a couple of real world scenarios that apply to any project plan.

You're relatively new on site, new to this particular project, or perhaps new to project management. Nothing wrong with any of those by the way.

You're of the opinion that as a project manager you should be able to tell the client where he's going to be in 3 months time (reasonable). The client is applying pressure for a project plan so he knows what the next 12 months looks like and there is a requirement to commence resource planning as soon as possible. A common enough set of circumstances. 

We can approach project planning in any number of ways, but I'm going to make a useful distinction between two approaches. In doing this I'm going to mis-use a couple of terms - who knows maybe it will catch-on and then it'll be correct use.

We can adopt a 'top-down' planning approach where we define the duration (say 12 months) and then attempt to undertake delivery of the project's scope in this time. Or, we can adopt a 'bottom-up' approach in which we define the PBS and WBS (I discuss these in previous posts), elaborate the work and resources required to deliver the work and let our project planning software tell us when the work will be finished.

For me, the imperatives that serve project sponsors and project management are conflicting, difficult to reconcile and are a re-current source of tension. It should be as simple as enshrining the approach in the PID, mandate or other documentation, but in my experience it isn't.

Let's look a bit more at the various advantages and disadvantages of the two approaches.

In theory at least, I'm all for top-down project planning. Sponsors define the durations (and I might add the scope and budget) and authorise (compel)  the delivery of the project's scope within a that duration. All sounds terribly straight-forward doesn't it? But then, I am of course reminded of the words of Commander C. Theo Vogelsang, USN “… in its relationship to strategy, logistics assumes the character of a dynamic force, without which the strategic conception is simply a paper plan.”. I don't think anyone has ever put it better than Commander Vogelsang.

A positive zoo of wise pragmatism on the subject of logistics from military theatres can be found here.

So, while we like top-down planning, we now recognise that it's not the be all and end all. 

So - let's have a look at bottom-up. We have a scope, that we're going to elaborate into a product breakdown structure, create a work-breakdown structure that will deliver the product breakdown structure and commence delivery. Well, no, you're not. You probably won't have a detailed project scope at the outset of a project, you won't have any funding to commit resources to the work necessary to deliver the WBS and PBS, let alone enter into the commercial contracts potentially required to deliver the actual work. In fact, you won't even get past funding approval.

Some readers may be falling back on a bit of real world experience at this point and envisioning that we commence project start-up with the top-down plan and successively work towards a bottom up plan and in reality that is not uncommon. However, this too has its problems as funding and cost expenditure profiles are often aligned to the top-down plan, and don't necessarily adapt well to that schedule being destabilised by something as annoying as a plan that actually reflects the work that needs to be done and the duration that it will take.

Recognising that I'm beginning to drone on interminably here, I'd better quick bring the end of this post into view.

Consider the following illustration. Hopefully this is broadly self explanatory. The only note I'll add is that (particularly in my field of technical infrastructure, there will always be an unalterable volume of work required to get a job done. Short term variances arise in the identified or forecast volume of work due to imperfections in diligence and discovery at the start and blunders during the work's execution. Below I refer to this unalterable volume of work as 'K'. 

In an ideal world, Kt is about the same as Kb which is about the same as K. in reality you never know K until you've finished your project. However, deciding on how important it is to know Kt or Kb accurately, or the acceptable variance between these and K should be decisions made with full disclosure at the outset of the project start-up. Needless to say - any decision should be data driven and the criteria that might inform this decision might include; cost, criticality, complexity and risk.

I think there's a few more interesting observations to be made for the illustration above - but I'm not going to elaborate that too much. What does it mean for your project's in your organisation?

More yet to come on forecasting.

Management, governance and a partridge in a pear tree

I do read quite a few other blogs and there must be something about the year end that elicits a desire in bloggers to report on what they did well during the past year, what they won't do in  the next year, emerging trends and must haves for the ensuing 12 months. You get the picture. I'm not so sure I have much to add to the existing canon but it has spurred me to be just a shade more speculative that is the norm.

I include some points below which might be worthy of a moment's consideration in terms of positive change to the overall landscape of project management

1. Project Complexity Modelling. For clarity, this is an approach to modelling how complex a project is and there is some coverage of this topic in the (former) OGC's Portfolio, Programme and Project Offices – P3O literature here. However, it's subjective, qualitative and not (in my experience) used. I'd like to see something quantitative, something that was capable of analysing a network diagram and, ideally something that allowed you to manipulate a project's plan or scope to influence (reduce) any given project's complexity.
2. Getting change practitioners a seat on the board. CEO, COO, CFO, CIO, C3PO? (you heard it hear first). My view is that a business's ability to undertake change effectively and efficiently leads to a significant overall competitive advantage. Supplement this with 'poor governance' being an oft cited cause of project failure and isn't it time the business of change took its seat at the top table?
3. Configuration management (bit of a misnomer this one). I like to think of myself as a generalist PM, an aspiring 'project manager's project manager' if you will. I do acknowledge however that a lot of my thinking comes from 15 or so years working in assorted I.T. environments. In any I.T. environment, configuration management (the management of your configured items) is a cornerstone of a well managed I.T. estate. Get this right and you have the opportunity to get most other elements right too. Get this wrong, and this opportunity will elude you. In very succinct summary, the CMDB (configuration management database) should in most cases facilitate an answer to the question "what should I worry about if I change this specific item". It provides a map (of varying quality and granularity) of what is joined up to what. There probably is something similar in the world of project management - the portfolio view, the PMO, the integrated programme and project management tool-sets - call them what you will. There's never been one when I've needed it.

And I think three things will do nicely. Three's a good number in management - military organisations the world over have known this for quite a while hence, there are three sections in a troop, three troops in a company, three companies (or thereabouts) in battalion an so on.

And that's not a bad hopping off point for the next point. Ask five people in a room what management is and you'll get six different answers. I always come back to the point that if something isn't being planned, controlled and directed, then it isn't managed. And furthermore, that things that are managed are predictable, sustainable and controllable. I think most of this relates pretty well to points 1 to 3 above.

(Incidentally, if you ask five people in a room what governance is, you'll get 3 answers, 2 questions and a partridge in a pear tree - but that's a topic for another day).

So after all I might have something to add to the overall cannon of project management rhetorical introspection. A bit more management in 2013 would just do nicely.

Forecasting part deux

Vicissitudinous. Now that isn't a word you'll hear everyday, let alone everyday in the field of project management. But is should be and if it wasn't such a challenge in terms of spelling and pronunciation, my feeling is that it would be a good deal more used than it is. In short - prone to adverse change.

As is my habit, in my last post I talked at some length about the shortcomings of the Pert weighted average. I'll try and suggest one or two improvements.

First however, a simple suggestion that quite apart from any estimating technique will help immediately with the accuracy of your plans and the forecasting effort.

Keep your tasks short in duration / work - never longer than week, ideally to a maximum of 2-3 days. Decompose your tasks to a level that can be undertaken by one person.

Sounds obvious doesn't it? I have however lost count of the number of project plans in which a few vague words (usually something like "Re-provision host environments" or some such hides 300 man days of work and a 60 day duration. And when, as surely you must, you enquire as to the specifics of the host environments and quite what their 're-provisioning' entails you'll often be greeted by a wall of jargon or a dismissive wave of the hand which suggests if you don't know already, you shouldn't be asking. 

Keep digging. How long does it take to change a tyre? Actually, I'm not certain - but I know the following questions are easier to answer.

1. How long does it take to remove the spare from the boot?
2. How long does it take to jack up the car?
3. How long does it take to unscrew the wheel nuts?
4. How long does it take to find the locking wheel nut adapter? Ah-ha - you say you don't know where the locking wheel nut adapter is? Well, that's very interesting isn't it...

So you get the picture, decomposing the task through what is sometimes call 'progressive elaboration' is time well spent. Estimating shorter smaller tasks is easier and it tends to throw out details that might otherwise get overlooked.

I don't think I want to get too side-tracked here but I will take the opportunity to address a concern. The drive towards productivity very often means that planning phases are curtailed both in terms of duration and the degree of rigour that is sponsored / supported. Equally, there's often the (somewhat incredible) imperative to spend money quickly (usually this is about allocated budgets and financial drivers). In short, the PM is busy trying to create product breakdown structures, product descriptions and plans that actually reflect the work to be done, and the project sponsor / board is saying - get on with it. Remarkable.

I'll spend some time on how to address this particular concern at a later date, but right now (for all you project sponsors who don't support detailed and structured planning) I offer the following. For your project to be any kind of success you will need to address the following.

1. You will need to identify all requirements
2. You will need to elaborate the work to deliver the requirements
3. You will need to identify and broker the resources to do the work
4. You will need to do the work to deliver the requirements
5. You will need to undertake such quality assurance work as is necessary to find defects in products being delivered.
6. You will need to fix any defects you find.
7. You will need to pay for items 1 - 6 above

Accepting (as I hope you will) that 1 - 7 are somewhat inevitable, you can do all that at the end of a project if you so choose. It's a darn site more expensive that way and tends to get up the noses of your stakeholders something rotten. Okedoke - I concede that I've wandered a little off my intended track here - but surely worth it for the word vicissitudinous alone!

Less poor forecasting (the first in a poorly planned and shambolic series of posts on forecasting)

Surely it can't just be me who thinks that estimating with the PERT weighted average is awful?

You know what I'm talking about (1 x the worst) + (1 x the best) + (4 x the most likely) all over 6. I guess that not any people can think it's that great, because I've never encountered anyone using it.

What then is the problem? Well first, what is the level of confidence in the output? Dunno. And I mean, really, you don't know. The principal problem is you don't know where the input figures came from. Likely as not, a bit of a stab in the dark in a workshop. At best, it will be sourced from experienced team members who have done something very much like the work before. This doesn't guarantee much as we shall see, but it's an improvement. Oh and the best bit, you're just as likely to corrupt a good figure as average out a bad one.

So what's wrong with a stab in dark? It has its place surely? We can refine things as we go can't we?

Let me cite two quick examples.

I'm working with a colleague over the phone - he's got the job of assembling a project plan. He's asking me about specific aspects of my work and putting 'durations' next to the work. We talk about a particular task and he offers that 2 days seems reasonable. I counter with 1 hour. Quite correctly he challenges this disparity. I'm able to have some level of confidence in my figure because I'd already done the work - and it took about an hour. We then quickly move towards a second activity which utilises the output from the first task. My colleague offers that the work will take around three weeks. I counter with 45 seconds. What he thought was a manual task was a bit of cut and paste with a spread sheet. 

If Pert weighted estimating is used in these two cases then the first example will be off by around 800% and as for the second, I'm not even going to waste time with a calculator.

So, two quick examples of how things can go off the rails. Now someone out there will be saying hold on, hold on; Pert weighted averages are only as good as the data that goes into them - same as any forecast. I agree up to a point, but there is no discussion or reference anywhere to this in the literature. Is there? Moreover, where do you get an optimistic estimate and a pessimistic estimate from? I've only got my best estimate, but usefully I'll tell you where it came from and often, what my level of confidence is in the figure. Oh - and not forgetting that there's not mention of how to deal with estimates that are either highly consistent or wildly divergent - and these two scenarios should be treated differently shouldn't they?


Let's set out a few immutable truths. Or at least some points which I hope won't raise too much debate.

Good things arising from good forecasting

1. Better project plans that build confidence
2. Better stakeholder engagement and perception - they know what's coming, when and in what order
3. Better management of commercials - you can sign those distracting multi-million pound contracts with a little less anxiety
4. Better expenditure profiling - you know what costs are coming when
5. Better resource planning, and importantly brokering. Just 'cos I said you could have 2 engineers this week doesn't mean you can have 'em next week...
6. More productive project boards - you're not arguing about the schedule all the time
7. A happier project sponsor

...and quite a bit more besides.

Bad things arising from bad forecasting

Quite apart from the absence of points 1 - 7 above are the following.

1. You'll constantly be re-working the project plan and your monthly project board will become your monthly re-baselining meeting.
2. Your project will quickly become a source of generalised uncertainty, consternation and (quite possibly) resentment
3. Your chances of getting to the finish line and fulfilling anyone's definition of a successful project will fairly quickly diminish to nil
4. And a real kicker here, you'll dilute your governance (who makes what decisions, when and to what criteria)

As is so often the case, my blog post has ended up in quite a different place than I anticipated (that of course is attributable to poor forecasting) but between this article and those yet to be published I'll try to provide adequate coverage of the following.

1. Parametric or reference class forecasting
2. Guessing, uncertainty and pragmatism
3. Never mind 6 Sigma - 1 will do you quite nicely
4. The PMs job in fighting for exactitude and rigour in the planning process
5. Some helpful language and strategies to challenge sub-standard practice
6. Some real life scenarios and tools consistent with other articles in this blog that I hope will add a bit of value

Ubiquitous constraints (and what to do about them)

For the record, when I say constraint I mean some circumstance or factor which limits an activity, benefit or the overall success of part or all of a project. (I do like to cast my net wide with these things!)

I personally think they're a bit under-nourished in the general scheme of things. I'm not at all certain that within most projects there's a consensus on what a constraint is. There's often little or no effort to record or track constraints.

I think most projects face constraints in various forms, but there are three in particular which are almost omnipresent.

Before I go too much further, I suggest that unless you're intimately acquainted with Eliyahu M. Goldratt's theory of constraints, there's no better time than now to hop on over to Wikipedia and brush up on what I think is some pretty smart thinking about the way the world works.

All the way back in 1984, Mr. Goldratt was putting pen to paper and publishing material that included the following:

Types of (internal) constraints

• Equipment: The way equipment is currently used limits the ability of the system to produce more salable goods/services.
• People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint.
• Policy: A written or unwritten policy prevents the system from making more.

*Source - Wikipedia

I don't have too many unbreakable golden rules but I do take the time to reflect on these three constraints roughly speaking at the following junctures.

1. Spend approval
2. Project start-up and initiation and every subsequent stage boundary
3. All discussions relating to project change

Equipment

The effective delivery of change can be hindered by simply not having the tools for the job.

Whether this is heaving lifting machinery, the right widgets, collaborative toolsets for the project team or specialist software tools it matters not.

How to defend against deficiencies in equipment? Good planning principally. Not altogether intuitively, a detailed product description can often identify the particular equipment requirements for the delivery of a product.

The PMO too (if you have one) should be a source of lessons learned, historical data, policies and standards of its own that illuminate requirements for equipment.

Lastly, subject matter expertise is often the differentiator between getting things right the first time or slowly learning the right way through time and patience.

Your approach (as ever) should be proportionate and informed by risk.

Policy

I've seen a few of ways in which absence of policy can seriously undermine project success.

1. The output of a project isn't used due to a lack of policy
2. Resources cannot be brokered for a project due to lack of sponsorship
3. Lack of stakeholder engagement (because no one's telling them any different)

I think this is my personal favourite having been caught on all three counts at one time or another.

The really simple answer (really far too simple) is simply get a clearer than clear project mandate. I've yet to see one. The less simple and less effective answer is wrap your project's mandate up in a terms of reference (PID probably, charter or brief maybe) and get that approved, authorised and sponsored.

If you're still worried, add it to the issues log - this won't help ever so much potentially, but you will have done your job as a project manager to the degree possible.

There's a bit of an addendum to this as well. There's (certainly in the UK public sector) an increasing drive toward the management and realisation of benefits (at last!). This can help the mandate / policy quagmire as all of a sudden, staff outside the project team are likely to be accountable for the delivery of benefits and this might get you an entry point to a discussion about policy / mandate or lack thereof.


People

You could spend a lot of time discussing the various human fallibilities that can constrain a project's success. I think there are pretty much three principal headings.

• Management
• Culture
• Availability

Consider the following to assist with the management of staff assigned to projects.

Responsibility assignment matrixes are (I think) very important in most projects. Projects are temporary, unique and time-bound (aren't they?). Thus, it is not reasonable to require a team to know what is expected of them unless they're told. And, in my sometimes prescriptive and process orientated world, telling people anything important should be documented, versioned and recorded.

I like the RACI chart - there are others.

Use a skills inventory. A skills inventory is a system or tool that identifies the skills and skill levels required to deliver your project, programme, specific work packages or products. It may also specify the individuals who possess those skills. Skills inventories are most effective if they are aligned with a particular programme.

I don't think it will often be within the scope of project manager's accountabilities to influence or manage cultural change within a project or programme team. I think this is one of those situations where if the culture isn't (for instance) delivery focussed, then you'll need to adopt a suitably appropriate posture to ensure the project's objectives are still attainable.

As far as availability is concerned, I cite the following.

1. Planning is criticial, as is estimating and forecasting. If estimating and forecasting is to be worthwhile, it must be based on historical data. One of the jobs of resource planning must be to specify what is actually going to be required in terms of resource burn.
2. Sponsorship from resource brokers (see policy above). This should be two fold. First, to release the resources for the period specified at the time specified. Secondly, to deliver (as far as possilbe) the scope of work agreed to schedule, cost and quality.
3. Manage change and issues so that deviations from what is agreed is predicatable, sustainable and planned.

On another occasion, I'll upload a RACI template and skills inventory tracker to the resources page.