UML Review–Views

A brief review of UML.

UML is a modelling system.  Every model is a simplification of the real thing and is intended to highlight the focus of that model and to recede what is not important for that particular model.   Reality cannot be modelled fully.  We will always have to select the perspective, or ‘view’, that we want to focus on.

UML is designed around a set of views. Its notations allow you to create diagrams that model a particular view.

Static View. The static view models the structure of the application domain. You use the Class diagram to represent the static view.

Use Case View.  Shows the functions of the system in its interaction with entities outside of it.  These entities are the ‘actors’.  The functionality is grouped together into use cases, where a use case is a specific transaction (or usage) of the system.  The Use Case diagram is used to present the Use Case View.

Interaction View. UML being object-oriented oriented (sic), entities communicate with each other through messages.  The Interaction View shows the message-passing interaction between the entities (strictly speaking, ‘between the roles’). UML has two diagrams that capture these interactions, the Sequence diagram, and the Collaboration diagram.  The Sequence diagram shows the messages and their sent between the different roles as each role requests and responds to the messaged.  The collaboration diagram focuses on the links between objects during an interaction.  So while the Sequence Diagram highlights the messages and their sequences during a specific transaction, the Collaboration Diagram highlights which objects are involved in the same transaction.  There is clearly some overlap between the two diagrams, and in practice, the Collaboration Diagram tends to be given up in favour of the Sequence Diagram.

State Machine View. Unlike the previous views, the State Machine view focuses on only one object or class.  This view models all the possible states of an object, what states it can transition to from each of those states, and what would cause it to transition to each of those states. The statechart diagram is used to draw this view.

Activity View.  This view maps the activities performed by whatever entity we want to model.  We do not have to pick an entity, in fact, and just proceed to model activities related to a particular outcome.  This view is similar to a project network diagram in that it simply maps dependencies and sequences of activities to produce a result.  You use the activity diagram to create this view.

Physical View. The physical views leave the world of concepts to model the physical realities.  There are two physical views in UML.  The implementation view shows the various software components and the links between them.  This is captured using a Component Diagram.  The other view is the deployment view, which shows the software components in the physical computers and servers they will be deployed in.

THE TRIPLE CONSTRAINTS ANOMALY

You cannot possibly be a project manager and not have heard of the term 'Triple Constraints', and the surest sign that you are a novice project manager is your belief that the Triple Constraints is made up a 3 things.

That is one of the odd things about this term.  Originally, it was indeed about three constraints: Cost, Time, and Scope – project and programme managers have to deliver the goods (Scope), within the budget (Cost), within the schedule (Time).

Later, thinkers thought to add 'Quality' because well, sure, you can deliver the goods, but are the goods you deliver up-to-spec?. So the Triple Constraints began to consist of four items.  There are some heretics (or perhaps they are prophets of wisdom) who insist that Quality is just part of Scope, and ought not be considered separately from the other.  The argument is, if you delivered 600 green umbrellas rather than the required 600 red umbrellas, it is not a 'Quality' problem but a Scope problem – you simply didn't deliver what was asked for.

Project managers with more than a week experience, began to realise that despite their personal charm, the world doesn't revolve around them or their naive assumptions. 

Things go wrong.

"We need to add another constraint - Risk", came the chorus. And so the Triple Constraints became five (and have to be redrawn as a pentagon – we are not geometrical ignorami, after all)

Courageous project and programme managers soon began to point out their specialty: delivering goods within the constraints of time, cost, scope, quality, and risks. There is no need to be mean-spirited by reminding them that postmen and newspaper delivery kids and mothers and housewives, have been doing the same since the invention of anything.

But no matter how well we think we manage the five constraints, projects still tend to head south, and so we need another constraint to lay the blame on.

Resources.

"Surely Resources are a constraint!" came the battle-cry of the project and programme manager. "Even if I have a budget of $50 million if I cannot find Fortran programmers, my Fortran project cannot succeed." And of course, when they burn up my $50 million without delivering anything, they can point to the incompetent resources they had to work with. 

But let's take a step back (after first checking we are not on the edge of a cliff; risk management in action).

We can take the view that the constraints are about what a project manager has to deliver against. Or we can take the view that the constraints are 'natural' limitations that enterprises have to balance when deciding which projects to undertake.

We want to finish the project as soon as possible so we can reap the benefits and start other projects as well. But to finish faster means applying more resources. This is a natural constraint in our world.

We want to do it right the first time, but it will mean more time and more cost, so we may need to cut a little bit of scope here and there. Another natural constraint.

We want to deliver the project as cheaply as possible, but if we put a limited number of resources will take the project that much longer to finish. Another natural constraint.

I think the Triple Constraints are about having the enterprise (not the project manager) balance between the 3 (not six) constraints.  The project manager, for his part have to deliver the Triple Constraints while working through the constraints of Risks and Resources. (Quality is part of Scope).

Risk Velocity

Someone asked about ‘risk velocity’ in the Linkedin discussion groups.  She was asking about its use as a criteria in prioritising risks. But she was also interested about the term itself. Why ‘velocity’?  What did the (so far anonymous) coiners of the term have in mind?  The original poster notes that definitions of the term were very vague. 

Subsequent comments from the other posters bear this out – it seems everyone had their own thoughts about what risk velocity meant.  I myself had none, having not heard of this term before.

One poster suggested that risk velocity is about the ‘timeframe within which the risk event might occur’.  That is, ‘risk proximity’ (which begs the question – what’s the difference between the two?).

Another poster posited that risk velocity is not the proximity of the risk itself, but the time to impact of its consequences.  That is, how much time do we have before the consequences happen after the risk occurs?  This poster rather correctly points out that the common measure of risk, which is “probability x impact”, tells us nothing about when either the risk or its impact might occur.

A third poster comments that he sometimes uses ‘Velocity of Risk’ to describe the state of the financial market.  Presumably, during a volatile situation, the velocity is higher.  This is somewhat akin to wind velocity, blowing more violently in a hurricane, and much more calmly in normal weather.

A commenter named Val brings forward her own use of the term. If I understand her correctly, she uses risk velocity to describe how the risk grows the longer it takes to mitigate its occurrence.  Her example tells me she is talking about the impact growing the longer we wait to mitigate. 

Someone named Peter chimes in, properly noting that ‘velocity’ is a vector – a measure containing both magnitude and direction.  He posits that perhaps the term includes (or should include) the idea of something that is moving in a certain direction. Perhaps we are running directly into the risk (or the risk is bearing directly towards us), perhaps it might be a glancing blow, perhaps it may bypass us.

Yet another poster writes that her use of risk velocity is about assessing the likelihood of an event in a specific timeframe, that is, assessing that an event has a 50% chance of happening in the next 3 months, is much more useful than merely saying it has a 50% chance of happening.   While certainly sound, I just don’t see that this has any connection at all about velocity.

In a later post the original poster reveals her own understanding,  which is that risk velocity was about the rate of change of the likelihood, and not at all about the impact.

There were dozens of other further comments, too many to note here.  Some went beyond the original question, but providing interesting insights.

But what of it?  What about risk velocity?  Can it be used to rank risks?  I think the idea of getting a  good understanding of when a risk might occur (risk proximity) and how soon the impact will happen after the risk event occurs is sound, but very inadequate. 

First, which impact are we talking about?  The initial impact?  The follow-on impacts?  The maximum impact?  You need a good understanding of the impacts, when they will occur, how they will occur, in which order, and so on.  Some impacts will occur immediately, some will occur later.  How can a single risk velocity number capture these characteristics?

Risk velocity, as a singular number to be used for ranking risk events according to when their impact is to occur after the event, might appear to be simple and useful.  I think it has a use as a label to allow us to find those risks which may have a early impact, but as a prioritising value, I find it to be too ambiguous and potentially misdirecting.

Ten Lessons from ‘Intellectuals and Society’

Thomas Sowell’s ‘Intellectuals and Society’ describes what drives intellectuals, and what damages they have produced – and continue to produce – to society.  Typical of his other works, this one cites many references to back up its claims.  This is not a book written by solitary pondering.  Sowell could not have written this book without considerable time and effort exerted at compiling sources.

The ten lessons listed below are not the ten most important things this book says.  They are not even necessarily the most important things I learned (the items are not even listed in any order of importance).

I simply wanted to list down ten things I learned while read this book.

1. Special Knowledge – Many types of knowledge exist. Intellectuals possess a ‘special’ kind of knowledge that is not found in the general population. But this knowledge is taken (often wrongly) to be more important than ‘mundane’ knowledge.  Intellectuals often stray very far from their area of speciality, forgetting that knowledge does not necessarily travel with them as they cross other territories.  Chess grandmasters may be the pinnacle of intellectual skills in that game, but they themselves recognise that expertise in chess does not translate to expertise in politics or economics or indeed something closer, like poker.  Intellectuals seem to brush away this fact.  Even the very smartest intellectual possesses only a minuscule fraction of the knowledge of the general public.  Even taken collectively, the total knowledge of intellectuals is dwarfed by the knowledge of everyone else as a whole. 
   
2. Who Intellectuals Are – for the book’s intent, intellectuals are people whose work ‘begins and ends with ideas.’  Intellectuals do not build anything.  They just produce and propagate ideas.  There are many other professionals who engage in work requiring very high mental demands, but whose work does not end with ideas and therefore Sowell does not regard them as intellectuals (for the purpose of this book).  This latter kind include surgeons and doctors, engineers and architects, lawyers and business men, scientists and mathematicians (although Bertrand Russell when acting as a non-mathematician is included in the list of intellectuals).
   
3. Verbal Virtuosity – intellectuals very often frame reality with an inventive play of words to recast this reality into what it isn’t. They do not necessarily do this on purpose.  Very often it just happens as a result of an intellectual’s ignorance of the subject matter. Sowell gives the example of intellectuals calling for the abolition of ‘mandatory retirement.’ He says there has practically never been such a thing.  People who were let go by they employers due to age have always been free to work elsewhere.  They were not required by any law to not work anymore.
   
4. Intellectuals Have a Depp Need to be Recognised – because intellectuals do not do helpful work daily, they have a need to come up with new, exotic, exciting ideas. Whether there is proof that these ideas work is almost ignored.  They want to change the world.
   
5. Intellectuals can be Epic Fools – Sowell provides evidence that intellectuals have been supporters of Stalin, of Hitler, of unilateral disarmament in the face of Nazi Germany rearming, and many other examples.
   
6. The Media Does not Report on Reality – if you think about it, if the media reported only facts, people would not find them very interesting.  The media, like the intellectuals, have an interested in the new, exciting, and exotic.   Sowell unfortunately does not give guidance on where can find the facts, if the media cannot really be trusted.
   
7. Intellectuals Often Ignore Empirical Evidence – Intellectuals judge ideas, not by empirical evidence of its goodness, but by characteristics like ‘novelty’, ‘exciting', ‘complex’
   
8. Social Vision – Intellectuals have a ‘vision of the anointed’ , a vision of a world unable to improve without their (the intellectuals) wisdom and intelligence.  This vision Sowell contrasts with the ‘tragic vision’, where there is no solution – everything is a trade-off, civilisation people just lead their lives making their own choices in a world where civilised society is a veneer over barbarism forever threatening to spill out – and we can’t do much about that except strive to contain it.  This section is one of the harder parts for me to side with Sowell.  Much of society’s progress (material progress at least) is due to capitalists who have a vision of the world and who have staked their reputation and assets trying to put that vision (I would put the likes of Thomas Edison and Henry Ford, even though Sowell does not mention them).  Perhaps I have not understood it well yet.
   
9. Don’t Let the Intellectuals Run Your War – Sowell blames the intellectuals for the stunning weakness of France’s performance in World War II, despite it material military advantage.  He blames France’s military failure on the supine psychological attitude of the French, inculcated into its youth by the intellectuals running the education system.  Had it not been for pragmatic leaders like Winston Churchill,  intellectuals would have had Britain disarm completely in the naive hope that Hitler would do the same.  (Had that happened, I think Western Europe would be completely either under Nazi or Soviet rule)
   
10. Judges Shouldn’t be Making Laws but They are – Laws are supposed to be made by the Legislative branch of the government, and judges are to judges individual cases in light of those laws.  Judges sometimes rule in ways that make their rulings applicable ex post facto.

Eliciting Requirements

I was reading Mike Cohn’s book ‘User Stories Applied’.  He starts his chapter on gathering stories by pointing out that ‘Elicitation and Capture should be Illicit’.

Clearly, this is a play at words.  But the idea is that (to him) ‘elicitation’ rather improperly conveys the notion that ‘requirements are out there somewhere and all we need to do is have them explained to us and then we can lock them in a cage.’

He prefers ‘trawling’, a term he says was introduced by James Robertson  and Suzanne Robertson (‘Mastering the Requirements Process’).  The reason for his preference?  Trawling conveys the idea of a trawler (a boat that catches fish by dragging a large wide net behind it). 

Its a confusing argument.  If there is a word that conveys the capture of something that is ‘out there’ – exactly the image that Mike wants to get away from – it is trawling.

From Merriam-Webster’s Dictionary of Synonyms: “Elicit usually implies, pains, trouble, or skill in drawing something forth or out; it often implies resistance either in the person or thing that is the object of effort.’

‘Elicitation’ is far superior to ‘trawling’ when it comes to describing the process of gathering, extracting, and identifying requirements.

User Stories and Roles in Agile

The Agile approaches in system development rely very heavily on the concept of user stories.   A user story is a brief statement about how a specific user might use the system so that he achieves a specific outcome.  It is often stressed that this outcome must be expressed as something of value to the business.

An example user story might be: ‘As a system administrator, I can configure the access rights of users, so that I can restrict access to sensitive areas of the system.’

Identifying the users of the system to be developed is one of the first steps the development team should take (see for example Mike Cohn’s ‘User Stories Applied’).  To ‘identify’ users does not mean identify the actual persons, but rather to identify roles. 

A role is the capacity in which the user interacts with the system.  An example of a role might be the system administrator who is in charge of configuring and maintaining the system.  Another example is an assistant who is responsible for printing reports from the system. A third example is a data entry person who uses the system to input data. And so on.

In addition to the organisational position occupied by the user, it is also encouraged that the system designers further look at finer grains of the roles.   Rather than simply think of the system administrator as one role, think of possible types of system administrators because doing so can bring insights into what the role will need when using with the system. 

A highly experienced system administrator very familiar with the system will have different needs than an experienced system administrator new to the system, who will also have different needs from a system administrator by accident, and so on.

By further classifying the roles, we begin to realise that not all system administrators are the same.  They have different backgrounds.  They may have the same responsibilities, but they may have different capabilities and capacities.

Mike Cohn recommends the project team to hold a brainstorming session near the beginning of a system development project to identify the various roles that will be catered.  In this session, every team member writes down roles that they think about.  After everyone has written down the roles, the team collects the list and refines them, merging similar ones, and further splitting others.

A couple of observations can be made:

1.  The way some authors use the phrase ‘user’ they seem to be not very clear whether they refer only to those who will be actually using the system.  If that is the case, the definition excludes those stakeholders who do not use the system, and therefore some other exercies is needed to identify the larger set of stakeholders. 

For example, if the system is an immigration department front-end used by immigration officers (and never touched, or even viewed, by passengers), are passengers to be considered as users?  I would suggest they not be considered as users, but should be considered as some other kind of stakeholder (a very important class of stakeholder; not to be ignored), and a separate exercise to identify these kinds of stakeholders need to be performed. 

2.  I would also suggest that after identifying the users, and cleaning up the list, a second exercise be taken to note down the key interest of the user with regards to the system.  Why does this user have to interact with the system – what are their responsibilities to the organisation? 

Some Thoughts on Jobs

A resume is a marketing tool, nothing more, nothing less.  Everything in it must contribute to getting the reader think you might be the right person for the job.  However, it is a mistake to overstate things in your resume.  You will be correctly identified as a liar.  As with any marketing effort, make yourself appealing, but don’t overpromise.

If the resume is a marketing tool,  the interview is the selling forum.  This is where you close the deal (no resume ever closed the deal).  Try to find out the company’s problem (why are they willing to spend thousands of dollars a year on someone?).  Show them how you can relieve them of the problem.   An interviewer has a few concerns:

• Is this the right person?  (Would I be in trouble if I select this person?)
• Is there someone better?
• If this is the best person for the job, what if I can’t get them?

Address these questions.

Do you worry about being overqualified?  If you have a leak in your house and you need a plumber, do you worry about whether the plumber you get is overqualified?  You certainly would not want to get a professor of plumbing who only knows the theory, but you shouldn’t worry about getting someone who has fixed 100,000 leaks in their lifetime. 

The Product Owner in Scrum

What is the role of the Product Owner in Scrum? 

The product owner’s responsibility is to ensure that the product is developed and delivered in a manner that maximises the paying owner’s return on investment.  In Scrum, what this means is that the product owner must identify for the Team those product features that deliver the highest business value for money amongs the outstanding product features not yet delirvered.

There is the assumption that there will never be enough money to build every desired feature.  Therefore, the features need to be prioritised.

The Product Owner does not dictate to the Team the specific set of features they need to build in a Sprint.  

Specifically, the Product Owner does not tell the Team how many features they ought to build during a certain Sprint – that decision belongs to the Team alone.  The Product Owner’s main role is to inform the Team of the priorities, so that they don’t proceed to deliver lower value features over high value ones.  There can be exceptions - for example a lower value feature may be included in the Sprint over a higher value one because the higher value one is too big to be added to the current Sprint, while the lower values one is small enough to be added.

It is possible that the product owner is the customer, but he or she must never be the Scrum Master.

The Systems Engineer Genie

A whimsical look at what it could be like if the genie has been trained as a Systems Engineer.

A man walks along the beach and comes across a magic lamp.  He rubs the lamp, and out comes a Genie.

“Greetings, Master, I am a Genie from INCOSE.  Your wish is my command.” says the Genie.

Excited, the man says: “I want a million dollars!” and holds out his hands, anticipating the goods.

But nothing happens.

The man demands: “Where’s my million dollars?”

Genie: “I am an SE Genie. That’s not how we work.  First, I have to understand what it is you want to achieve, and help you come up with the best solution.  Master, why do you need a million dollars?” 

Man: “What ?!? Ok I want a million dollars so I can quit my job not have to work anymore!  Give me my money!”

Genie: “Ok, so you’re not happy with your job.  We should look at the different possible solutions to that problem and not jump to conclusion about the solution.  For example, perhaps you can move to a different job?  I can grant you a new job.  Or how about I make it so that you enjoy your current job.  Say, if we make you the boss?”

Man: No, no, no!  I want a million dollars so I can enjoy myself.  So I can do what I want, like travel, eat good food and drink great wine.   I don’t want to work anymore.

Genie:  Ah I see.  Now, instead of a million dollars, what about a lifetime free air travel?  And lifetime free meal vouchers.

Man: No, I want money!

Genie: OK, I guess we have settled on the concept of operations. You get money, and spend it on whatever you like.  Now, let’s get the requirements right.  Are you talking about Australian dollars, US dollars, Brunei dollars, Hong Kong dollars?

Man: “US dollars! A million US dollars”

Genie: Great, How do you want to receive it? In cash? In coins? Deposited to your bank account? A lump sum? An annuity?

Man: “What?”

Genie: How does this requirement sound:  “The genie shall arrange to deposit a million US dollars into the following bank account XXX-XXXX no later than 5 business days from today.”

Man: Great! Let’s do it.

Genie: We’ll also need to agree on how you will VERIFY that you have received the million dollars.

Man: “What?”

Genie: Verification, how will you check that I have fulfilled your wish?

Man: Ok!  Uh… I will check my bank statement, and if I see a million dollars, then we’re fine.  I will also sign a document saying: WISH GRANTED.

Genie: Then we have to integrate the money into your life.  How will you explain this to the tax authorities?  Do you have any outstanding debt?  Should the money be placed under your name or to a legal entity?

Man: Forget about those things and just give me my damn million dollars!

Genie: We also need to think about the effectiveness of this proposed solution.  Like, will 1 million dollars be as as 2 million dollars?

Man: Just give me 100 million dollars !

Genie: Granted!

And the man got his 100 million dollars and got investigated by the tax authorities and his money got frozen by the anti-money laundering regulatory commission and the man spent the rest of his life paying legal defense bills, all because he ignored the sensible analysis required by the SE Genie.

The Likelihood of an Event

The biggest constraint in risk management, indeed the very reason for the existence of the discipline, is our inability to foresee what will happen next. 

In most cases where people have to manage the risk of an event, it is very common to rely on subjective estimates of the likelihood that the event will happen. It may be easy to deliver criticism of this approach, but alternative options are limited.  

An improvement over such a simplistic 'gut feel' approach is to incorporate the phenomenon that events of a smaller scale occur at a higher frequency than similar events of bigger scale.  Earthquakes of low magnitude occur very frequently. Killer earthquakes occur far less frequently. 

The relationship of the frequency between the two types of events is described a the Power Law Distribution.  If we keep track of smaller scale events, we will be able to predict with a certain degree of confidence the frequency of the bigger scale events.

***

Deciding That a Crisis is Upon Us

A key challenge that needs to be met in the face of a serious situation is determining whether we are in a crisis or not? Whence is the transition from non-crisis to crisis? Is it time to initiate the crisis management plan, or not yet?

The US military gives us a good model of crisis with the DEFCON
status. It allows a staged reaction to a crisis that may be impending
or may not be impending.  It allows the military to prepare and also not to over-prepare.

As facts become known, and the understanding of the situation becomes more solid, the authorities are able to step up or step down preparations
and mobilisations for handling the crisis.

Business organisations would to well to think about a staged approach to
their crisis management plans.

Checklists

Checklists and questionnaires belong in the toolbox of risk professionals. A checklist works best when used by the risk professional while interviewing an information source, whom we’ll call an interviewee. 

The checklist becomes far less effective when simply handed over to the interviewee because when you let the interview work by himself,  it raises new undesirable dynamics:

• First, the interviewee loses the chance to ask questions about the questions being asked.  He may misunderstand what is being asked, but unaware of it.  In such a case, even if you informed the interviewee that they should ‘feel free’ to ask if they have questions, will not help much, because in this case, the interviewee is not even aware that they misunderstand.
• Second, the interviewee may not have as much interest as the interviewer in the process of gathering data.  In cases like this, you can expect that only the minimum amount of information will be written down in the checklist.
• Third, the interviewee may not see the whole point of the interview, and why they must fill in the checklist. As in the second dynamic above, this results in lacking information.
• Fourth, a large number of checklists and forms are very badly designed, which can easily lead an interviewee to confusion. Many forms ask for too many things. The interviewer may have energy to fill in the first few entries, but a noticeable drop in energy due to a drop in interest can often be seen.

A well designed form helps much toward eliciting good information.  At the very least, the following should be addressed when designing questionnaires and checklists:

• Who is going to use the contents of the checklist?
• To what purpose are they going to use the contents?
• Who is going to provide information to the checklists? (That is, who are the interviewees)
• What kind of questions and prompts should the checklist contain in order to elicit the information required?
• What kind of information does the current version of the checklist contain that are not needed?
• In what ways can the questions and prompts be misunderstood?

It is vital that a checklist be tested on several interviewees first before finalising it use.

Risk Management Software Packages

In a LinkedIn discussion someone asked for recommendations on a web-based risk management software package that’s suitable for a SME (small to medium enterprise).  The key need was for managing a risk register and for tracking risks.  Some of the recommendations were:

• @Risk (http://www.palisade.com/risk/)
• Balanced RiskCard (http://www.riskcard.co.uk/)
• Active Risk Manager (www.strategicthought.com)
• Link ResQ (http://www.linkresq.ie)
• RiskAid or RiskAid Enterprise (http://www.riskreasoning.co.uk/)
• STREAM (www.acuityrm.com)
• Covalent Enterprise Risk Manager (http://www.covalentsoftware.com/product/erm/)
• EsyRiskManager (http://www.dnv.com/)
• Pims (www.omega.no)
• JCAD RISK (www.jcad.com)
• Magique (www.magiquegalileo.com)
• Aon RiskConsole (http://www.aon.com/denmark/en/esolutions/aon-risk-console.jsp)
• RiskyProject (http://www.intaver.com/riskyprojectprof.html)
• (http://www.align-alytics.com/)  (what product?)

This is quite a handful of choices. I’m hoping to be able to spend some time lokking into each one.

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 modelled 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 doing the task will normally take 7 days to accomplish this task, but has other stuff on his plate, therefore it may take more that 7 days for him to complete the task.  Why?  Because his 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, his machine might break down, he could misunderstand the specifications,  or what's required of him 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..

Project management

Any undertaking, no matter how small, faces the possibility of taking longer than anticipated and costing more than expected. In addition, there also exists the danger that the job will not be done right. Or if indeed done right, was not what we thought was needed.

The bigger the undertaking, the bigger the likelihood of unwanted problems occurring.  The culprit is complexity.

Consider the undertaking of changing your shower curtain versus the problem of defending Normandy beach from Allied invasion.  Yes, you might slip on the floor and bang your head while doing the former, many, many more things could go wrong in the latter (and many did).

One is more complicated than the other. It is this (vast) difference in complexity that makes the other undertaking much more likely to have potential problems. Complexity is like having open doors and windows where problems are free to let themselves in. The more complex the undertaking, the more numerous the open doors and windows.

We could stay small and be content with simple undertakings, but our society's progress will be limited. We can choose to limit our undertakings to nothing more complex than mastering the art of candle-making, but our society will not progress much. If we want progress, we have to face complexity. 

Fortunately, we have tools at our disposal. 

Look at the skyscrapers and other technological marvels we now have.  Science and engineering has progressed such that it is now possible to design buildings that will not randomly fall down. We now know how to design such buildings. Complexity and its associated problems have been reduced by scientific and engineering knowledge.
But we like to push the envelope, and so complexity remains.

Every undertaking requires activities. No activity, no undertaking. The more complex the undertaking, the more numerous and varied the activities are.

Activities depend on and interact with other activities, and therefore must be coordinated. Those who need to fit glass windows to a building cannot start working until the building structure has been built. Those who need to test software cannot begin until there is some software to test.

Knowing how to design a building is not the same as knowing how to organise the activities required to build that building, and vice versa. They're not the same thing.  The training, skills, and mindset is different. The orchestration of these activities demand a different kind of knowledge, attention, and discipline from that required to design a building.

To harness the benefits of science and engineering, there is another discipline that was developed to help us with our complex undertakings. This discipline is intended to help us manage the activities and ensure that:

• We can have a confident estimation how long a undertaking will take, so we can plan for it.

• We can have a confident estimation how much the undertaking will cost

• We can identify the activities required to complete the undertaking.

• We can ensure that the undertaking will take no longer than planned

• We can ensure that the undertaking will cost no more than planned.

• We can ensure that the undertaking will be completed.

• Everyone's valid expectations are met.

That discipline is called Project Management.

What is the difference between an impact and a risk?

Sit at any Risk Management 101 class or Risk Management introductory workshop and you will most certainly be introduced to the risk register. And in that risk register, you will be introduced to two columns: the Risk, and the Impact. 

You will be told that the Risk is an event that may or may not happen.  You will also be told that Impact is what will happen if the Risk occurs (or ‘eventuates’). Sounds clear, simple, direct. 

Now let’s apply what we’ve learned.  You are concerned (rightly) about crashing your car. Is that a risk? Or is it an impact?  (Avoiding the pun on crash and impact). It is not certain that your car will crash, so that is a risk.  What will be the impact?  Easy: you may experience fatality.  Or you may experience serious injury, or you may experience light injury. 

But why isn’t crashing the car an Impact? 

What caused the car crash? Did your brakes malfunction?  Was that a risk?  Was there a risk that your brakes would malfunction?  Were you hit by a drunken driver? Was that a risk you faced when you were driving? Absolutely.

So let’s say: Risk = Possibility of being hit by a drunker driver.  What is the impact?  Crashing your car.  What was the risk earlier is now the impact.

The distinction between risk and impact is not so clear.  What is a risk from one perspective is an impact from another.  But which perspective is the right one to take? And which perspective should you be taking when you fill in the risk register?  Do you put “Car crash” under Risk or under Impact?

Winning and Risk Management

There’s a highly-regarded self-coaching book called “Sail, Race, and Win”, by Eric Twiname and Cathy Foster. In the book is a neat description of how to win in a race.  They ask the reader to imagine a descending escalator, with lots of people, representing the competitors, walking up the escalator.  The goal being to remain in the same spot they started in as much as they could manage to. They can walk up to the same pace that the escalator is going down, but they can't walk up faster than that.

Since no one’s allowed to go faster than the pace of the escalator, the would-be winner will have to focus on not making mistakes rather than walking faster than the pace of the escalator.  Any mistake, no matter how momentary, will set you back a little, possibly allowing someone behind to move out in front of you.  The more mistakes and lapses you make, the more you are pushed back relative to your starting position, and relative to the other competitors.

Now since you can't go faster than the pace of the escalator, you can't make up the distance you lost by putting in extra effort. The best you can do is to make no more mistakes.  The only way you can get ahead of those in front of you is if they make mistakes.

I haven’t seen winning explained in this manner before, and despite its oddness, it has a certain valid point.  Twiname and Foster come from the world of sailing.  Perhaps the idea of not being able to outpace the escalator comes from their world, where your progress depends on the winds and the tides -- you can't go faster than what the elements or the environment allows.

The image seems rather useful when thinking about how risk impacts business.  A company cannot make more money than what its environment allows.  For example, if you are a consumer goods company, how much you can sell is moderated by the size of your market, the demand for your product, and the competitive dynamics of the industry you are in. In a market with 10,000 customers and 5 competitors, you just cannot make sales equivalent to a market of 20,000 customers.

And while you can't get ahead, you can definitely be set back.  The key to winning then becomes minimising the setbacks. From an operational basis, you are constantly being set back if your production costs are more than the competition’s. From a discrete and pulsating basis, you are set back each time a risk eventuates which impacts you negatively.  The longer and more expensive it takes you to recover, the more you are set back.  The key to winning in this case is to ensure that you minimise your risk eventuations and minimise their impacts.

You can look at risks as these setbacks.  It is in your interest to avoid them as much as possible, and to be able to recover as quickly as possible.  Even then, you can only recover to a point less better than where you started. Hence, reducing the occurrences of risks become a key factor in winning.

Is managing a project like conducting an orchestra?

Managing a project is so frequently compared to conducting an orchestra that the comparison has almost become a cliché. 

I understand the comparison. There is a slight similarity between conducting an orchestra and managing a project. The similarity lies in the fact that both the conductor and the project manager do not make the actual product. They simply orchestrate the work of those who produce.: a conductor controls the performance of many different specialists, combining the individual performances into one single harmonic product.

There are a couple of key differences though.

The first difference is that an orchestra has had time to rehearse and practice over and over exactly what they are supposed to do. Indeed, they must refine their work until it is flawless, before the actual live execution.  A project team hasn't got that luxury.  It has only one pass at executing the project.  

An orchestra will never be asked to work faster, redo a task, or cut the scope of a musical piece.  There is no such thing as crashing the music by playing faster.  Project teams have deadlines to meet and often need to redo work and work faster than normal.  An orchestra performance is an operation. It is perhaps the smoothest of operations.  There is no change of plans.  The audience's (stakeholders) mood will not change what the orchestra will play or how they play it.

But then again, why use a conductor as the focus of an analogy? Every orchestra presentation has an actual project manager orchestrating it, scheduling the rehearsals, picking the team, picking the conductor, selecting alternate members, etc. 

I think a more appropriate example is that of a coach in a basketball game.  The coach does not deliver the points, he manages the team so that they deliver the points. 

What shall I write about?

What is this blog for?  Why did I put up this blog?

First, I want a place to write down some of my thoughts, and play with them.   Writing helps you clarify your thoughts.

Second, this provide a place for me to communicate some of my ideas.  You may find them useful, or you may find them dangerous and mistaken (in which case, please let me know).

Third, this is an outlet to write in a less formal way and to sharpen my writing skills (and boy do they need sharpening).

Fourth, this is a place for me to jot down ideas that get my attention.

What subjects will I cover?

I do not want to limit my subjects, but it will surely include those areas of my professional interest: systems engineering, project and programme management, risk management, lean and agile solutions, organisational behaviour, computing, etc.

Who is my target audience? 

Me.  I am writing mainly for myself, but you are welcome to listen in.

The Working Advisor

The title of this blog is inspired by Leonard Sayle’s book, "The Working Leader: The Triumph of High Performance Over Conventional Management Principles"

A leader gets his hands dirty and interact with the day to day environment, adjusts his ideas to accommodate reality.

I am a consultant.  To many people, the word consultant brings to mind a professional who comes in to an organisation, looks at problems, writes up a document recommending solutions, and then leaves, without having any responsibility for implementing those recommendations.  Oh, and the sends a huge invoice for his services.

I believe a consultant is one who, although they may do the above, stays and helps execute the ideas they recommend. 

Execution and implementation reveals faults.  There is no harsher or more fair judge than reality.  Ideas that look good on paper may collapse when tried.