SCERT Approach to Risk

A risk is an area of uncertainty.  This uncertainty can turn into risk events that may prove unfavourable to a project.  Risk events are not always necessarily unfavourable. 

Whether is will rain or not, for example, is a risk for someone planning to go on a picnic.  The risk events could be that it will rain heavily, or it will rain lightly, or it will not rain.  The area of uncertainty, that is, the risk, is the possibility of rain.

Managing project risks is about analysing the risks (uncertainties) that a project is facing, identifying the risk events that may come out of that risk, planning responses to these events, monitoring the chances of these events, and executing responses to the risk events.

The SCERT approach to managing risk begins with breaking down the project into manageable components.  Because nothing is certain, every single task in a project has some risk (uncertainty)  Much of that however, is handled in the scheduling process which (must have) used a probabilistic approach (for example a 3-point estimation in PERT).

We only look at the major uncertainties. 

Break the project into components. SCERT recommends no more than 20 components for large projects, and no less than 5 components for small projects.

If the concern is for risks affecting the schedule, breakdown the components by activities.  If the concern is risks affecting the cost of the project, breakdown the components by cost components, highlighting their expected costs. 

Once the project has been broken down into manageable components, the process of identifying the sources of risk (again, uncertainty) can be identified.

* * *

Communications - Being Understood

The famous line: "what we have here is a failure to communicate" elicits chuckles.  People recognise the experience these words describe. The words resonates with many people because the experience is very common. 

We've all had experiences of miscommunication.  You may recall colleagues who never let you finish a question -- they answer the question even before you have even gotten midway through your question.  Of course the answer you receive has no relation to the question you were intending to ask.

For a project manager, miscommunication is  a professional tragedy.  A project manager's job is constantly about communication.  He doesn't do the actual work.  He organises, orchestrates, informs, and instructs.  He uses communication to do these.  A project where the manager instructs the team to do something, and the team comes back with something else can be heading for trouble.   Miscommunication consumes time, energy, money,  increases tension, and decreases motivation in the workplace.

Dowling & Sayles says that for communication that instructs to be effective, it must meet a few criteria. 

First, the message itself must be understood.  Understanding is hard, it is easier to misunderstand.  To understand something is to get exactly what is meant. To misunderstand is to get something wrong, even a very little something.

One of the problems is words.  Words are never very precise.  Someone said that words are cups that people fill with the meaning they want.  Think of the words you often use in your projects: maximise, prioritise, quality, improve.  Do they mean the same thing to everyone?  These could all be understood in different ways.  When you come across communication that uses words that come loaded with meaning, make sure to explain in more detail what you mean by the word.

Managers should practice getting feedback about what they are communicating.  How do you know that what you said is what was heard? One way to get feedback is to ask the other party to restate what you just said.  This works for some people.  You can ask your staff to repeat what you said.  You can also practice it yourself, repeating what other people say to you, to help them ensure that you understood them correctly.  It is not as easy to ask your superiors or clients or some people to repeat back what you said.

Another way to check if they understood you is to ask questions about what you said, trying to get a hint of what they think you meant. 

Once your communication has been understood you have crossed one barrier.  There are two more to cross.

The next question is, yes they understood what you said, but did they believe you?

Take Me to Your Leader

Depending on which management writer was asked, the visitors from space would be directed to different people.  These writers seem to have different definitions of leadership and thus leaders.  Some simplify it to 'leadership is about dong the right things, while management is about doing things right."

Leadership is about doing the right things. Not really,

Leadership is about having a vision.  Not really, everyone has visions and dreams.

Leadership is about a charismatic and powerful personality. Not really, there are charismatic and powerful personalities who are not leaders (almost every movie celebrity)

Leadership is a process, influencing others to perform something.  Like selling or marketing or mugging?

Leadership is about authority and power.  There are many people in positions of authority who cannot command.

My current view is that leadership is about having followers.  Without any followers, you are not a leader.  That is all it is.  To take the lead means to be the leader.  Without followers there is not lead to take.

Success and Failure

Is success the opposite of failure?  I wonder if there's a middle between the two: a non-success, non-failure middle. Consider if you focused your efforts on making sure your projects succeed versus making sure your projects do not fail.  Will you be doing the same things? 

Something more concrete: what is the most important thing you can do on your current project to ensure it succeeds?  What is the most important thing you can do on your current project to ensure it doesn't fail?  Are they the same?

Hierarchy of Objectives

Project success is defined in terms of meeting project objectives.  One example of an objective is meeting the project schedule.  If the project meets that schedule, then the project is a success.  What makes things tricky is that projects have more than one objective.  The project is required to meet this schedule, but within this budget, and without having any scope left behind. 

Besides the traditional constraint triangle, there are other objectives: ensuring the project team is happy, ensuring the the project stakeholders are happy, etc. 

Not all of these objectives are equally important. Some are more important than others.  That is why team members are asked to work on weekends rather than letting the schedule slip.  That is why team members are often asked to work without extra pay -- to ensure the project budget is not exceeded.

In a project, it would be helpful to prepare a list of objectives and rank them in order of decreasing importance. That way, all objectives are kept in mind, yet at the same time clear which objective is more important. 

The list might best be kept private.

An approach to planning

Planning a project involves identifying the activities required to deliver the project and the inter-dependencies between those activities.  These activities and the dependencies are then modeled onto a network diagram.

Task duration estimates are often padded, as a matter of good practice, but also as a matter of covering one's behind.  Things often don't go according to plan and one has to allow for that.  If I estimate that task A will take 10 days, and I say it will take 10 days, and then something goes wrong, then not only do I look bad, I might also I end up delaying the next task which was set to begin 10 days later.  So the common practice is to be generous with our estimates and pad them for contingencies.  Such padding implicitly addresses the risks faced.  

There is another approach that integrates project schedules with risk management, and at the same time highlights the possible sources of these risks.

One way to bring this planning to a different level is to first make a realistic and optimistic estimate of how long each task will take.  Let's say if a task will take 7 days if no problems occur, then we start with 7. We do the same for each task. Then we study the task and its dependencies and try to understand what could go wrong that can cause its accomplishment to exceed 7 days.  Then we try to address those things that can go wrong.

Let's say the person executing the task will normally take 7 days to accomplish the task, but has other stuff on their plate, so may take more that 7 days to complete the task.  Why?  Because their time and attention could be diverted to the other tasks.  If we don't highlight this reason then we can't manage it.  Suppose we identified that this person really has other stuff on his plate, then we can take steps.  We can schedule his task to be done after he has finished his other stuff, or we can arrange things so that he suspends work on other stuff, or we can just accept things as they are and simply pad the number of days.  At the very least, we have identified a possible cause of problems.  

There could be other factors to consider: this person could get sick during that time, their machine might break down, they could misunderstand the specifications,  or what's required of them and then we will need to redo things, and so on.

By thinking through the possible reasons for exceeding the optimistic estimate, we begin to identify possible causes of delays and we begin to be able to plan for those causes: try to minimize their chances of occurring, minimize the impact if they occur,etc.

***

Tip of the Day - Estimating

When scheduling any task, especially a time-consuming task, it is always prudent to assume the task will take longer than you expect.  

Things happen.  

Therefore, add an allowance as a contingency.

This is not padding schedules for the purpose of billing higher.  Neither is it about covering your behind and ensuring you deliver before the target date.

It is simply common prudence.

If you believe a task will take 3 days and you promise to deliver it in 3 days, whoever is depending on your task may decide to commit himself to starting their task 3 days later, on the assumption that you will have delivered by that time.

If you fail to deliver as scheduled, then he will probably fail to deliver his task as well.  This chain could go on through to several persons.

Not adding a contingency to your estimate is not merely being gung-ho, it's plain irresponsible.

In addition to adding a contingency to your estimate, however, you must also be prepared to work on the next task if the current task gets completed sooner than scheduled.

Delivering on Scope

Many writers on project management tell us that project management is about delivering the project on time and on budget, with a special emphasis that project management is about the 3 constraints of quality, cost, and time.

Turner writes that project management is about managing the scope and the organization, and that quality, cost, and time are just constraints.  Consider that the reason for the project is the work to be done (in order to reap the benefits of the project). 

Without the work, there is nothing.  Next, consider that the project organization is what does the work.  Without them, there is nothing.  The other three features: quality, cost, and time are not the purpose of the project. They are simply constraints. 

Handbook of Project-based Management

Succeeding by not failing

We keep on building systems that experience failure mainly because we don't learn from our previous failures.  In fact, if only we made a formal effort to study the cause of previous failures, the 'vast majority' of failures would disappear.  This seems to be the thesis of a  book on system failures from Joyce Fortune and Geoff Peters.

The phrase 'system failure' normally brings up the usual suspect of 'computer/information system failure' , and that's not surprising. Information Systems chalk up more than their fair share of failures, or at least the failures that are interesting enough to make the news. One of the reasons is that these systems tend to have so much failure is that they are so embedded in organizational life that there are so many points of interaction and therefore so many points at which failure can occur.

Information Systems are also now so entwined in our social and cultural life that we experience failures almost every day, from a dropped internet connection, to a stolen credit card number.

 

While failures will always happen, a lot less of them would happen if only organizations made proper, formal reviews of what caused previous failures, and then apply the lessons learned, argues Fortune and Peters.   To aid in this noble aim, they have devised an approach called the Systems Failure Approach, an approach solidly grounded in the principles of systems thinking.  SFA lets its user extract failure events from the real world, construct a systems model of the failure using systems techniques and, from the understanding gained come up with a lesson that can be applied back to the real world.

On Agile...

You've heard said it before: in order to learn one must have an open mind.

I think sometimes the opposite is better. Keep a closed mind. Let the new idea try to make its way in with difficulty. Let it argue itself in with facts. Let it convince you of its correctness. Once convinced, make it your own. If the idea has enough merit, it can make its way in.

I've been trying to like the Agile methods, but for reasons I still cannot pin down, I am still pessimistic about these approaches. There is no doubt they work. Sometimes. But that's not a criticism. Nothing works everywhere. Agile's more moderate proponents have never suggested that is applicable everywhere.

I should clarify that I am pessimistic mainly about the XP approach, since that is the methodology I am most familiar with among the agile methodologies. I am still agnostic about the rest.

These methodologies have been developed because of the unworkability of the one-pass waterfall approach. In an ideal world, where people do not make mistakes, the one-pass waterfall is the simplest and most efficient approach to developing software: complete the requirements in one phase, then complete the design, then complete the programming, then complete the testing, and finally, complete the acceptance, and we're done.

But since we're not mistake-proof, the waterfall is simply impossible as an approach, and no one in their right mind will attempt to develop software using this model. Except in the business world, of course.

Here's one of my issues. No one has been complaining that the programming phase of a waterfall approach comes out with a program that does not match the design documents. No one has been complaining that the design documents do not match the specified requirements. In other words, the problem is not with the design phase and it is not with the programming phase. The problem is, and always have been, that the specified requirements do not match the actual requirements.

If that is true, then it is the domain of requirements analysis that is at fault. They come up with the faulty requirements. The domain of software design and programming is just fine -- give us the correct requirements and we'll give you the correct software.

An approach that tries to fix the system development problem by fixing the software design and development phases rather than the requirements phase is looking under the wrong lamppost. And I think Agile is doing just that.

Be that as it may, I'm currently reading Robert Martin's Agile Software Development and have more to say on the topic.