Tuesday 28 February 2017

Ship of State Metaphor


I recently completed Jim Benson's book "Why Limit WIP: We are Drowning in Work". It's a simple, straightforward read, in the form of a story around typical life pressures in a corporate running multiple projects, all with the same sense of urgency, but teams not actually shipping any product (that is, completing any work product and releasing to market).

Jim introduces a metaphor called the Ship of State, as a way to help the team's product and project managers navigate through the uncertainty, thus allowing the team freedom to decide (empowered) what is safe and within their control to make decisions and others where the team still need to act, but still keep the stakeholders informed of their thinking. The scene is around product features for roadmap, which I thought quite powerful and useful - with a much wider application than just roadmapping features.

So I created this little poster that captures the essence of the metaphor. Does it makes sense?
Think about what your ship of state would look like (personal or professional)....
Ship of State

Friday 24 February 2017

Signs of Stress every Project Professional should know


When you're working on projects you will experience many challenges: from working on multiple, often conflicting and ambiguous priorities, multiple streams of work (tasks, work packages, etc.) as well as interacting with many different types of (difficult) people, from different cultures, behaviours to different languages spoken. Your customers (stakeholders, client, sponsors) will vary in quality, more often than not applying pressure for their work getting done (because more than likely its linked to some kind of personal objective / business reward). This pressure is usually passed down to the project team members assigned. With the focus on delivery & timeline pressures, the project manager is often forced to multitask, expecting the same from project team members who often have the challenge of juggling between between project and non-project work, multi-project work (generally people are assigned to more than one project at a time) and not forgetting people's own personal/life (family, health, etc.) challenges thrown into the mix.

All of this can become too much, and as a project professional (project manager), who's primary responsibility (in my humble opinion) is to ensure his people are led, directed, guided, coached through the implementation phase of the project thus meeting expectations of the customer and coming away intact, that it behoves the project manager to be aware of the common signs and symptoms of stress. After all, we work with human beings, not machines that are oblivious to mood swings, emotional problems and simple pleasures - so being mindful of your team members state-of-mind, as well as your own -- and taking time to truly pause and reflect, adjusting your behaviour as a project manager can go a long way to not only improving your work relationships, but also can help with the the successful outcome of your project implementation.

The American Institute of Stress (AIS) stated that the term "stress" was coined by Dr. Hans Seyle in 1936, who defined it as a "the non-specific response of the body to any demand for change". He sometimes defined it as "the rate of wear and tear on the body".

Here are some fifty common signs and symptoms of stress from the AIS. Look out for these in your own life as well as the people you work with.
  • Frequent headaches, jaw clenching or pain
  • Gritting, grinding teeth
  • Stuttering or stammering
  • Tremors, trembling of lips, hands
  • Neck ache, back pain, muscle spasms
  • Light-headedness, faintness, dizziness
  • Ringing, buzzing or "popping" sounds
  • Frequent blushing, sweating
  • Cold or sweaty hands, feet
  • Dry mouth, problems swallowing
  • Frequent colds, infections, herpes sores
  • Rashes, itching, hives, goose bumps
  • Unexplained or frequent allergy attacks
  • Heartburn, stomach pain, nausea
  • Excess belching, flatulence
  • Constipation, diarrhoea
  • Difficulty breathing, sighing
  • Sudden attacks of panic
  • Chest pain, palpitations
  • Frequent urination
  • Poor sexual desire or performance
  • Excess anxiety, worry, guilt, nervousness
  • Increased anger, frustration, hostility
  • Depression, frequent or wild mood swings
  • Increased or decreased appetite
  • Insomnia, nightmares, disturbing dreams
  • Difficulty concentrating, racing thoughts
  • Trouble learning new information
  • Forgetfulness, disorganisation, confusion
  • Difficulty in making decisions
  • Feeling overloaded or overwhelmed
  • Frequent crying spells or suicidal thoughts
  • Feelings of loneliness or worthlesness
  • Little interest in appearance, punctuality
  • Nervous habits, fidgeting, foot-tapping
  • Increased frustration, irritability, edginess
  • Overreaction to petty annoyances
  • Increased number of minor accidents
  • Obsessive or compulsive behaviour
  • Reduced work efficiency or productivity
  • Lies or excuses to cover up poor work
  • Rapid or mumbled speech
  • Excessive defensiveness or suspiciousness
  • Problems in communication or sharing
  • Social withdrawal and isolation
  • Constant tiredness, weakness, fatigue
  • Frequent use of over-the-counter drugs
  • Weight gain or loss without diet
  • Increased smoking, alcohol or drug use
  • Excessive gambling or impulse buying

Check out this Human Function Curve by Nixon in 1979, that illustrates the generally accepted view of the effect of stress on worker productivity. It is entirely personal and shows that each person has their own individual limits for stress - there are good stresses and bad ones. Zero stress = Zero performance - interesting.
Human performance peaks at modest amounts of stress. (Source: Nixon, p: Practitioner 1979)

Credits / Reference Material
I came across this topic from this book, Chapter 2 on The Human Behaviour Problem as Root Cause: Multitasking from Critical Chain Project Management by Leach

Saturday 18 February 2017

The Immutable Laws of Project Management


I came across this classic list a while back and was reminded recently about it in Critical Chain Project Management by Leach, so I thought it useful to store as reference (yes, it's already online, but I actually enjoy writing things down as a way to reinforcing my memory).

I can personally identify with all these laws in my history of working on projects, how does your experience compare :-)

The Immutable Laws of Project Management

LAW 1
No major project ever completes on time, within budget, with the same staff that started it, and the project does not do what it supposed to do. It is highly unlikely that yours will be the first.
Corollary 1: The benefits will be smaller than initially estimated, if they made estimates at all.
Corollary 2: The system finally installed will be late, and will not do what it is supposed to do.
Corollary 3: It will cost more but will be technically successful.

LAW 2
One advantage of fuzzy project objectives is that they let you avoid embarrassment in estimating the corresponding costs.

LAW 3
The effort required correcting a project that is off course increases geometrically with time.
Corollary 1: The longer you wait the harder it gets.
Corollary 2: If you wait until the project is completed, it is too late.
Corollary 3: Do it now regardless of the embarrassment.

LAW 4
Everyone else understands the project purpose statement you wrote differently.
Corollary 1: If you explain the purpose so clearly that no one could possibly misunderstand, someone will.
Corollary 2: If you do something that you are sure will meet everyone's approval, someone will not like it.

LAW 5
Measurable benefits are real. Intangible benefits are not measurable, thus intangible benefits are not real.
Corollary 1: Intangible benefits are real if you can prove that they are real.

LAW 6
Anyone who can work effectively on a project part-time certainly does not have enough to do now.
Corollary 1: If a boss will not give a worker a full-time job, you shouldn't either.
Corollary 2: If the project participant has a time conflict, the work given by the full-time boss will not suffer.

LAW 7
The greater the project's technical complexity, the less you need a technician to manage it.
Corollary 1: Get the best manager you can. The manager will get the technicians.
Corollary 2: The reverse of corollary 1 is almost never true.

LAW 8
A carelessly planned project will take three times longer to complete than expected. A carefully planned project will take twice as long.
Corollary 1: If nothing can possibly go wrong, it will anyway.

LAW 9
When the project is going well, something will go wrong.
Corollary 1: When things cannot get any worse, they will.
Corollary 2: When things appear to be going better, you have overlooked something.

LAW 10
Project teams detest weekly progress reporting because it so vividly manifests their lack of progress.

LAW 11
Projects progress rapidly until they are 90 percent complete. Then they remain 90 percent complete forever.

LAW 12
If project content is allowed to change freely, the rate of change will exceed the rate of progress.

LAW 13
If the user does not believe in the system, a parallel system will be developed. Neither system will work very well.

LAW 14
Benefits achieved are a function of the thoroughness of the post-audit check.
Corollary 1: The prospect of an independent post-audit provides the project team with a powerful incentive to deliver a good system on schedule within budget.

LAW 15
No law is immutable.

My library on Project Management

Here is a live list of all the project management books I own in my personal library. I have read every one from cover to cover. Each one has helped me in some way or the other in mastering the art and skill in project management, that I now find myself less interested in the detail of project management, but rather more interested in the project leadership aspects of the domain: setting strategy, starting-up and shaping projects, forget date-drive tracking and focus on building commitment instead, building relationships, program report visualisation (one page project manager reports, Toyota A3, etc.) & simplification (cut-down meetings, reduce waste, manage work-in-process), running & facilitating workshops (brainstorming, scoping, discovery, pre-mortems, retrospectives), organisational change & transformation, playing coach, guide, mentor and advisor to PMOs & Execs.

This list is in no particular order but towards the bottom end are the most recently read books. Not sure where all the icons disappeared to, but the links should work.



Monday 23 January 2017

Applying the 80/20 rule to my personal RAGE model

Last year I shared my RAGE model (Reality, Aspirations, Goals, Expectations) that could be applied to both personal and professional development (I also created a template that other people could download and use for their own use here). My aim was to make sense of my life-work balance (I used to call it the popular "work-life" balance, but later decided that life is actually more important than work, and now I use "life-work" balance instead. I'm not yet won over by the "integrated work-life" idea just yet although I see the point that you really can't separate out "work" as it's an essential part of your "life" - but I maintain the separation as it helps me categorise my personas better). 

I started by defining personas (basically activities like husband, father, professional, individual, friend, colleague, etc) where each persona reflected some facet of my life, that would consume time & energy. For each persona, defined related aspirations and goals for the year(s). As time is the most critical resource, I needed to understand:
  • What activities were consuming the most amount of time?
  • How did reality (of actual time consumed) compare against my wish-list of aspirations (desires, wishes, fancies)
  • Find a way of relating my time spent on activities relative to the value / happiness gained from such activities
I used Harvest for time-keeping, which I maintained with as best discipline as I could, and started tracking all my activities from the end of January 2016 till December 2016. Going into 2017, I will continue to track my time, making a few modifications going forward.

Last year, my reading centred around self-improvement - I also studied the works of Richard Koch on the 80/20 principle (after having read about it in Tim Ferriss' 4-Hour Work Week). The 80/20 principle was inspiring and relevant to my experiment in exploring my life's activities. Since I was collecting the data of time logging my activities, I would have enough data to use the 80/20 tool to gain additional insights: Which 20% activities consume 80% of my time? Which activities do I most enjoy compared to my actual time spent? What are the vital few activities that have the highest impact in my life? What activities or personas did I start out with are actually irrelevant and can be assigned to the trivial many?

In this post I will examine 2016 under this 80/20 lens and share my revisions for 2017 year ahead. The experiment continues ...

I often get asked why do I invest my time in this experiment? Why do I share this stuff on my blog?
I believe in this experiment - when I started this journey I felt I really needed to inspect my life and not live on auto-pilot, doing the same things day in, day out (which most people do) ad infinitum. I wanted to examine myself, explore my value system taking myself to task: Am I really living the life I had pictured in my head or am I just fooling myself? When I began this experiment, I had not even heard of Tim Ferris or Richard Koch for that matter, or the group called Quantified Self. Now, after studying these people, I know I'm not alone in this, that reaching a state of self-awareness is crucial to making sense of the world, and most importantly coming to terms with reality and finding peace with ones self. Personally I've learnt that it actually does help to write things down, create personal plans and logs with some goals that can be measured and tracked using journals, introspection and other self-reflection tools (it does not have to be a thing assigned to your job in the workplace). This experiment calls me to order: why am I complaining I don't have enough time to pursue my own goals and interests? Why am I blaming the world and passing excuses on to others (like family commitments) when the reason for not achieving my goals comes down to just plain laziness, distractions & lack of motivation? Did I bite off too much that I could chew, am I being over ambitious? Do I need to slow down and see reality for what it really is? How do I adjust myself, re-calibrate on the few essential things that make me happy?

I write about this stuff because blogging is a hobby. It might not get me anywhere, I do it for myself, and take the risk of sharing this stuff in the public domain because it just also might be relevant to someone else, who knows. I also use this medium as an outlet. A lot of my blogging in the past year has been on self-improvement & self-discovery, both personal and professional, which is a phase I currently find myself in...the feedback I've got from both colleagues and friends have nevertheless been encouraging and thus further motivates me...I've shared the RAGE model with a few people, it strikes very interesting conversations indeed. Some people have even suggested I teach this stuff!

Inspirational Quotes

"Finding out what you love to do is a great feat in and of itself"  Derek Dolin

“There is no satisfaction that can compare with looking back across the years and finding you’ve grown in self-control, judgement, generosity, and unselfishness.” – Ella Wheeler Wilcox


“There is only one corner of the universe you can be certain of improving, and that’s your own self.” – Aldous Huxley

“There are three things extremely hard: steel, a diamond, and to know one’s self.” – Benjamin Franklin

“It is not only the most difficult thing to know oneself, but the most inconvenient one, too.” – H.W. Shaw

“The man who views the world at fifty the same as he did at twenty has wasted thirty years of his life.” – Muhammad Ali

For more quotes on self-discovery, click here.

2016 under 80/20 lens

Richard Koch's 80/20 Principle is a book that everyone should read. I'm not going to rehash the 80/20 principle, except state in the general terms of the greatest output / reward (80%) is achieved through 20% of the input (vital few), the law of non linearity and unbalanced systems; that 80% of success results from 20% of input.

Monday 7 November 2016

Enterprise Agility Workshop

I recently held a workshop with senior management (general managers and executives) of a large enterprise company on agile methods. In this post I share the framework that helped me execute the workshop, sharing the experience and points for reflection. 

The situation with this client is a typical enterprise organisation structure, divided into broad areas of "Business" and "Technology". Divisions within the "Business" include Customer Care Operations, Marketing, Finance and a PMO. Divisions within "Technology" included IT Business Systems, Digital Media Product Development & Consumer Technology. Strategy is a separate division altogether. Added to this mix is the Technology Division supports multiple business units, with each business unit sharing similar (but unique) operational entities. The tech divisions were also unique in that each applied their own flavours of delivery: two were agile (but had different implementations of methods like scrum / kanban), whilst the third implements a hybrid waterfall / iterative life-cycle. And lastly, these three tech divisions had their own flavour of delivery PMOs (so count that as four PMOs in total, plus another PMO for BI/Analytics group - so that's five PMOs!).

The business people's request was basically:
We work with technology teams that are using this thing called Agile. What is it? Can we have a workshop to review agile methods, to decide whether / what / if the full enterprise needs to do / change to become more agile? How can we deliver faster? How can we get technology teams to respond faster, given that we in business operations can't move as fast as technology?

I was doubtful to say the least, because to me, timing was everything. The dust hadn't settled yet due to recent (and ongoing) organisational re-structures within both business and technology divisions, so I was hesitant this workshop would not add much value. Anyway, the client insisted the workshop happen, so I had to make it happen.

Was the workshop a success? Well, my client would argue yes, it was a success and it's great that we made a start.
Did the workshop run as I expected? No, what I had in mind (see mind map), what I planned for and what actually transpired did not fully meet my expectations, still there were some lessons learnt, and validation of my ideas & experiments are useful, hence I decided to share the framework publicly.

How to frame the workshop?

My mindmap design for the workshop

This picture is the mind map I used as a guide to planning the workshop. I applied my RAGE model as a guide, looking at:
  • Reality - I needed to understand the current reality of the stakeholders, in terms of their knowledge and experiences with agile methods?
  • Aspirations - Wanted to understand what problems they wanted to solve?
  • Goals - How could I run the workshop to address some of the stakeholders goals?
  • Expectations - What were these guys expecting as an output from the workshop?