Posted on

Triple Constraint: Time, Cost, and Quality

Triple Constraint - Time Cost Quality

Triple Constraint - Time Cost QualityTime, cost, or quality. Choose one. They are the corners of the triple constraint. And this is the most basic, most important idea within Project Management.

Project Management itself is a Big Idea that we have already covered. But when you are leading a project, the triple constraint is your guiding compass. It gives you the bearing for every decision you need to make.

Continue reading Triple Constraint: Time, Cost, and Quality

Share this:
Posted on

The Cone of Uncertainty

The Cone of Uncertainty

The Cone of UncertaintyThe Cone of Uncertainty is a concept from the world of Project Management. But, as an idea, it is so compellingly simple and so widely applicable, that it deserves a place of its own in our Big Ideas series.

So, in this article, we’ll take a look at what the cone of uncertainty is, and how it makes a helpful mental model in many contexts.

Continue reading The Cone of Uncertainty

Share this:
Posted on

Agile Project Management

Agile Project Management

Agile Project ManagementHow do you adapt traditional project management into a rapidly changing environment? One that is characterised by shifting priorities and high uncertainty. Arguably, you don’t need to – project management has always had the tools for this. But, with the Agile Manifesto of 2001, software projects have a new paradigm. A modification of traditional approaches, called Agile Project Management.

And make no mistake… Agile has become a ‘Big Thing’. In fact, it bears some of the hallmarks of a fad, while also having a lot to offer an informed organisation with wise and pragmatic project leaders to call upon. But, as with all good ideas, it also attracts its converts and zealots.

Of course, here at Management Pocketbooks, we tend to eschew extreme and simplistic ‘right versus wrong’ arguments in management. We’re here to suck out the good stuff and brief you on what it is and how to benefit from it.

Continue reading Agile Project Management

Share this:
Posted on

Project Management

Project Management

Project ManagementWhen you want to create something big, new, and complex, how do you keep all your tasks, time, and resources under control? The answer is Project Management.

We’ll never have the documentary evidence to prove it, but my assertion is that the discipline of Project Management goes back thousands of years. But even today, practice is evolving. In a world that is changing faster than ever, Project Management is a profession and a toolset that is becoming ever more valuable.

Continue reading Project Management

Share this:
Posted on

PRINCE2

PRINCE2
PRINCE2
PRINCE2

Project Management is an important skill, not just for professional project managers. Increasingly, managers of all sorts are called on to manage projects. And one big idea in project management is PRINCE2.

PRINCE2 was developed in the UK, for public sector projects. But there, some non-Governmental organisations have adopted it. Some have done so because they work with the public sector. Others because it offers a valuable framework for accountable projects.

The same reasons account for the uptake of PRINCE2 outside the UK. It is at its most popular in:

  • northern Europe (Germany, Netherlands, Belgium) and
  • the English-speaking world (Australia, South Africa and the United States)

Continue reading PRINCE2

Share this:
Posted on

Kanban

Kanban
Kanban
Kanban

Toyota is a powerhouse for developing ideas that you’ll find around the world. Take for example, Lean, Kaizen, Seven Wastes, Just in Time, Jidoka, Six Sigma and, indirectly, Scrum. And one more: I give you Kanban.

Pronounce Kanban as kaahnbaahn with long aah sounds. It started out as part of Toyota’s ‘Just in Time’ lean production system. The word refers to cards that visibly represented the flow of parts through the manufacturing process.

Now, we use Kanban tracking project work. It has risen in popularity over recent years with the rise of Agile project management. It is one of the more popular Agile methodologies. And it’s also often combined with the most popular approach: Scrum.

Continue reading Kanban

Share this:
Posted on

Hirotaka Takeuchi & Ikujiro Nonaka: Scrum Development

Hirotaka Takeuchi and Ikujiro Nonaka have featured in an earlier Pocketblog, which was focused on Nonaka and the work  he led on how knowledge can transform organisations.

Arguably, it is how Nonaka and Takeuchi took some of their thinking forward that has led to a far bigger transformation. In 1985, they co-wrote an article for the January 1986 edition of Harvard Business Review. Called ‘The New New Product Development Game’, this article was instrumental in revolutionising the discipline of Project Management.

Takeuchi and Nonaka gave us a new way of thinking about how to develop products and deliver projects. And they coined an evocative sporting metaphor for their process, which has stuck: Scrum.

Hirotaka Takeuchi & Ikujiro Nonaka
Hirotaka Takeuchi & Ikujiro Nonaka

Ikujiro Nonaka

Born in 1935, Ikujiro Nonaka gained a BS in political science at Waseda University, then started work at Fuji Electric, where he created their management programme. Nonaka left Fuji in 1967, to study at the University of California, Berkeley. He was awarded his MBA in 1968, and his PhD in Business Administration, in 1972. He took posts at US universities, before returning to Japan, as a professor at the Graduate School of International Corporate Strategy, Hitotsubashi University.

Hirotaka Takeushi

Born in 1946, Hirotaka Takeuchi got his BA from the International Christian University, Tokyo. After a short spell working at McCann-Erickson, he went to the University of California, Berkeley, where he got his MBA in 1971, and his PhD in 1977. During his time at Berkeley, he also worked summers for McKinsey & Company in Tokyo and, more important, met Nonaka.

Takeushi took a lectureship at Harvard in 1976 until 1983, when he joined Hitotsubashi University School of Commerce, where he became a full professor and Dean of the Graduate School of International Corporate Strategy. He stayed until 2010, when he returned to Harvard, as Professor of Management Practice, where he is now.

The New New Product Development Game.

In January 1986, Harvard Business Review published ‘The New New Product Development Game‘ by Takeuchi and Nonaka. This was about a new way to do New Product Development, or NPD. They drew on the idea of ‘ba’ – a Japanese coinage of Nonaka’s, meaning a meeting place for minds and the energy that draws out knowledge and creates new ideas.

They also took a look at the Toyota idea of teams coming together to solve problems. They introduced a sporting metaphor from the game of Rugby; that of the scrum. They used scrum to denote the way teams work together intensively when the ball goes out of play. In a work environment that demands creativity and innovative problem solving, this is just what is needed.

They followed this article up with a 1995 book, ‘The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation‘. This looks at the way Japan became a major economic power, especially in the automotive and electronics industries. they argue that Japanese firms are successful because they create new knowledge to produce successful products and technologies.

Scrum Teams

The model they created for Scrum Teams is of a cross functional group that can work autonomously to resolve its own problems. Their organisation is ’emergent’ meaning there is no assigned leadership or structure; it just emerges from the effective collaboration of its members.

To work best, a Scrum Team needs to be co-located, and work together full-time. This allows a high level of cross-fertilisation of ideas, and a dedication to working on their shared problems, tasks, and initiatives.

Scrum as an Agile Project Management Methodology

Agile project management seeks to avoid the all-or-nothing approach to projects that used to characterise traditional approaches – especially when done in a way that slavishly follows a set of ‘rules’. Although good project managers have always incorporated a lot of plan-do-review (the Deming Cycle), the growth of software development projects demanded an increase focus on agility and incrementalism.

This was the basis of the Agile movement and today the single most widely used Agile methodology takes its name and guiding principles from Takeuchi and Nonaka’s metaphor: Scrum.

In Scrum projects, a Product Owner is responsible for detailing the business requirements and ensuring that the business gets a good return on its product development investment (RoI). The Scrum Team, led by a Scrum Master, selects one subset of functionality from a product backlog of undeveloped functions, divides it into tasks, and works intensively on developing the outputs for a fixed time, known as a Sprint, which is usually 30 days.

Each day, the team gets together for a daily Scrum Meeting to share learning, report progress, discuss challenges, and solve problems. At the end of the sprint, the team should produce a working product that is stable and useful. After a reflection and learning process, the team then works with the product owner to define the subset of functionality it will work on in the next sprint.

The team continues like this until the Product Owner concludes that the next sprint would not create enough additional value to justify the incremental cost.

The Scrum Project Management Lifecycle
The Scrum Project Management Lifecycle

 

Share this:
Posted on

Eddie Obeng: All Change!

Possibly the first business book I read as a new publication was an innovative take on project management. The book had a charismatic style, much like that of its author. Its title is emblematic of the focus of Eddie Obeng’s career.

Eddie Obeng

Short Biography

Eddie Obeng was born in Ghana in 1959, and grew up in Britain, attending a boarding school in Surrey. He  earned a BSc in Chemical and Biochemical Engineering at University College London in 1980, and stayed on to take a PhD in Biochemical Engineering.

From there, he went to work as a scientist at Shell from 1983-5 and then to March as a consultant. During his time there, he took an MBA at the Cass Business School. This allowed him to move to the Ashridge Business School in 1987, first as an Assistant Director of Studies, and then, from 1990, as an Executive Director.

In 1994, he left to found Pentacle, an independent business school, which he still runs actively. He is also a visiting professor at Henley Business School and was awarded the prestigious Sir Monty Finniston Award by the Association for Project Management, in 2011, for his contributions to the study and practice of project management.

Obeng is the author of many books, most of which are self-published or out of print. However, All Change!: The Project Leader’s Secret Handbook (1995) is still available and I highly recommend it

Obeng’s Ideas

At the core of Obeng’s thinking is change. He has articulated this simply, by comparing the ‘old world’ with the ‘new world’.

Old World
We learn faster than our environment changes, so our learning equips us well, to cope. Stores of knowledge and experience are applicable and the learned thrive. We can build stores of best practice and we can afford long cycle times in developing new products and services.

New World
Our environment changes faster than we can learn, so our knowledge and experience are always out of date. Constant learning and adaptation is our only way of maintaining success. We need to find ways to develop and test new ideas rapidly and be prepared to honour ‘smart failure’.

Does this remind you of the Growth Mindset ideas of Carol Dweck? It does me.

Consequently, Obeng’s teaching is based around five disciplines we need if we are to succeed in the New World:

  1. Inventing the Future – Innovation
  2. Delivering the Future – project management
  3. Delivering Today – operational management
  4. Leading Organised Talent – leadership and team management
  5. Ensuring Results – sustaining change

All of this tracks back well to the central idea that attracted me to Obeng’s writing in the mid-1990s: that there are different sorts of change, which require different styles of leadership and different balances of capabilities and styles among team members.

These he describes as:

Going on a Quest

Goals and objectives of the change are clear, but you’ll need to figure out how to achieve them. You will need to think carefully about your resources, lead with confidence and commitment, and sell the benefits effectively. You need to stack your team with problem solvers and sleeves-rolled-up doers.

Walking in a Fog

Neither where you are likely to end up, nor the route you will take are clear. You need to move forward carefully and deliberately, one step at a time. You’ll also need to constantly reassure team members with praise for their contributions. You’ll need plenty of problem solvers and also caring people who can create strong team cohesion in the face of uncertainty.

Making a Movie

You understand the processes of change, but are open to discovering where the changes will take you. Consequently, professionalism and expertise are your your tools to ensure that the outcome will be right for your organisation. You need plenty of experts around you, who can follow processes correctly and innovate when needed.

Painting by Numbers

The clearest form of change is where the end result is evident and the means to get there are familiar. Excellence will come from precision and accuracy so it is vital to avoid the threat of complacency. As well as knowledge and skill, your team needs people who can monitor, review, and evaluate well.

This framework is now familiar to many project managers. We often learn project management as if every project is like Painting by Numbers, but it isn’t. My experience was very much with Going on a Quest projects, for example. The rise in Agile Project Management, from the mid-1990s is very much a response to this dynamic – particularly to Making a Movie and Walking in a Fog type projects.

Obeng’s charismatic style is not to everyone’s taste (see the video below), but his ideas are often stimulating and easy to grasp. At their best, they are also valuable aids to thinking about the world of work in the twenty first century.

Eddie Obeng at TED: Smart failure for a fast-changing world

[ted id=1580]

Share this:
Posted on

Risk Management

The Management Pocketbooks Pocket Correspondence Course

This is part of an extended management course. You can dip into it, or follow the course from the start. If you do that, you may want a course notebook, for the exercises and any notes you want to make.


We are now at the end of our series of blogs, looking at some of the essential models that a project manager will need. We have covered:


Project Management blogger Glen Alleman (at Herding Cats – a trenchant blog by a serious heavy-weight project manager) describes risk management as the way grown ups do project management. I thoroughly agree (and have written a book on it, ‘Risk Happens!’ to boot).

Why does he say this? I can’t speak for Glen (I wouldn’t dare) but my own feeling is that professional project managers have nailed the planning process as a fully developed skill set. So all the uncertainty in your project – and therefore the difference between success and failure – lies in the risk. This must take up a large part of your attention.

So let’s see how to do it…

The Risk Management Process

Risk Management is a simple process:

  1. Identify anything and everything that you think can go wrong
  2. Analyse each potential risk and prioritise them by assessing the impact of their consequences, and the likelihood of them happening. High likelihood, high impact risks are your top priority, and low impact, highly unlikely risks can be deliberately set to one side – you cannot ignore them, but you can choose to do nothing.
  3. For everything else, plan what you will do. Will you:
    • mitigate the risk by reducing its impact?
    • reduce the risk by making it less likely?
    • create a contingency plan in case it materialises?
    • find someone else to take the risk for you?
  4. Once you have your plans, put them into effect
  5. Review the outcomes of your interventions and, if necessary, plan and take further steps.

Risk Analysis

We analyse risks against their potential impact, their likelihood, and sometimes other factors like how soon they might affect us. The commonest tool is a chart of impact versus likelihood, onto which we plot our risks. The best approach is to keep it simple. Here is an example…

Risk Analysis

 

Further Reading

From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this:
Posted on

The Gantt Chart

The Management Pocketbooks Pocket Correspondence Course

This is part of an extended management course. You can dip into it, or follow the course from the start. If you do that, you may want a course notebook, for the exercises and any notes you want to make.


We are working through a series of blogs, looking at some of the essential models that a project manager will need. We will cover:

Once the dates are passed, these links will work.


The Gantt Chart is like a non-identical twin of the Network Chart which we saw last week. It contains all of the same information, but displays it in a different way.

The Gantt Chart is named after Henry Gantt, who did not invent it. As far as I can find (Wikipedia seems clear on this), it was invented some twenty years before Gantt re-invented it by Polish engineer and economist, Karol Adamiecki. Writing in Polish, of course, and calling it a harmonogram , would never endear it to Anglophone engineers and managers, who, if they had heard of it, would probably have thought Harmonogram too effete and musical-sounding a term. Gantt Chart has an air of brutality to its sound and Gantt was a thoroughgoing American.

Building a Gantt Chart

Anyway, let’s convert last week’s network chart into a Gantt Chart.

First, we draw two axes:

  • on one, put a time scale
  • on the other, list all of the tasks

Now, starting with the first task, represent each one by a bar. Make the length of the bar represent the duration of the task, and place it to represent its scheduling, as driven by the sequencing and dependencies of your network chart: voila!

First, here is our Network Chart

Critical Path on a Network Diagram

Now, let’s translate this into Gantt Chart format…

Gantt Chart

And it really is as simple as that… until your project gets large and complex.

Further Reading 

From the Management Pocketbooks series:

  1. Project Management Pocketbook

 

Share this: