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

Karol Adamiecki: Management Harmony

We tend to think of leading management theorists as coming from the United States. This seems especially so of Scientific Management. But when the privilege of naming things for the world’s largest audience goes to those who write in English, history creates a bias. And because that audience largely reads only one language, that bias gets amplified.

One of many losers from the Anglo-centric nature of management and business thinking was Karol Adamiecki. He was a Polish engineer, turned economist and management thinker, who can claim to have invented the Gantt Chart before Henry Gantt, PERT before the US Navy, the Theory of Constraints before Eliyahu Goldratt, and much of Scientific Management before FW Taylor.

Karol Adamiecki 1866-1933
Karol Adamiecki 1866-1933

Short Biography

Karol Adamiecki was born in southern Poland, in 1866. He studied engineering at the Institute of Technology in St Petersburg, graduating in 1891. He then returned to his home town, where he took charge of a steel mill. He stayed for nearly 30 years, during which time, he formed his ideas about management.

In 1919, he left the mill, and became a lecturer at the Warsaw Polytechnic, becoming a professor in 1922. There, he further codified and published his ideas. In 1925, he founded the Institute of Scientific Management in Warsaw, becoming its Director and remaining until his death in 1933.

Adamiecki’s  Law of Harmony in Management

While running the steel rolling mill, Karol Adamiecki developed sophisticated thinking around management that was, from our perspective, ahead of its time. The three principal components were:

  1. Harmony of Choice
    Management should select and supply production tools that are mutually compatible. He went on to argue that this should be especially so in terms of their output production speed. This anticipated the Theory of Constraints, and the ideas of Eliyahu Goldratt by 75 years or more.
  2. Harmony of Doing
    Sequencing and scheduling of activities need to be fully co-ordinated to optimise production efficiency. Here, he not only developed a tool that looks very similar to the Gantt Chart, well before Gantt published. His approach also anticipated the US Navy’s Program Evaluation and Review Technique (PERT) and du Pont’s Critical Path Method (CPM) by over 50 years.
  3. Harmony of Spirit
    I imagine the Pharaohs’ overseers were constantly emphasising the importance of creating a good team. But this is another theme that feels very modern – perhaps even more so than the other two. Let’s not forget that Taylor’s view of Scientific Management was mechanistic and process-oriented. It took Mayo to bring humanism to the fore, and ideas of team working in management only started to dominate from the 1970s.

Adamiecki started to publish in 1898, several years before Taylor did so.

Harmony of Doing:
The Harmonograph or Harmonogram (or Harmonograf)

In 1896, Adamiecki solved the problem of sequencing and scheduling in production and published, in1903, his solution. He called it a Harmonograf. And it looks very much like what we now call a Gantt Chart. However, Henry Gantt did not publish until 1910. There is no evidence to suggest Gantt copied Adamiecki’s idea.

In constructing the Harmonograf, however, Adamiecki describes a process that is pretty similar to the PERT and CPM methods. He certainly is able to include critical path and float. These are two concepts Gantt did not consider at all.

As Adamiecki described his methods, he was able to optimise production schedules by sliding paper tabs and arranging paper strips. In a very real sense, he developed an analog scheduling computer.


Without a doubt, Adamiecki’s thinking was of its time, but way ahead of its rediscovery. He possibly failed to realise just how valuable it was. But more likely, he simply suffered from an Anglophone bias in scholarship and manufacturing. Publishing in Polish simply did not get him recognition far beyond the borders of his home country. Even now, it is only in the Karol Adamiecki University of Economics in Katowice, that his name is celebrated.

And I have to ask, could this happen again? Yes. I think it can, will and probably is happening now. Last week, we met Vlatka Hlupic. Arguably, her work is known despite her Croatian origin, because she lives and works in London. With the US and the UK increasingly looking to close their borders for differing but related reasons, the next Karol Adamiecki’s work could well lay undiscovered for just as long as that of the first.

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

Henry Gantt: The Gantt Chart

Who invented the Gantt Chart? This is a question I ask in many of my project management seminars, and the commonest answer/guess is ‘Mr Gantt’. Why does nobody suggest Mrs Gantt? In fact, neither answer is properly correct. But nonetheless, the Gantt Chart is Henry Gantt’s enduring legacy. But there was more to him as a manager and thinker than that.

Henry Gantt

Short Biography

Henry Laurence Gantt was born in the southern US state of Maryland in 1861; the year the Civil War started. As one of my reference books puts it, the war ‘brought about changes to the family fortunes’. His parents were slave owners.

Gantt graduated from Johns Hopkins University in 1880 and, after a few years of teaching, qualified as a Mechanical Engineer in 1984, with a master’s degree from the Stevens Institute of Technology in New Jersey.

After three years working as a draughtsman in Baltimore, he joined the Midvale Steel Works in 1887. This is where FW Taylor was Chief Engineer, and Taylor was to become a mentor and important intellectual influence on Gantt. The two worked well together, and Gantt followed Taylor first to Simmonds Rolling Company and then to Bethlehem Steel.

They went their separate ways in 1900, and in 1901, Taylor endorsed Gantt as the best person to have as a consultant for implementing their shared principles of scientific management. This led to a successful career for Gantt; working with many large corporations. From this point on, though, Gantt was clearly thinking for himself and diverging from some of Taylor’s more extreme ‘scientific principles’.

It was in 1917 that Gantt ‘invented’ the now famous Gantt Chart, as a way to speed the construction of naval vessels during World War 1.

Gantt wrote two books – both out of print – and there is also a set of lecture notes available. Beware print-on-demand reproductions – some get poor reviews. His 1911 book, ‘Work, Wages and Profits’, focused on incentivising workers and marked a shift from Taylor’s penal approach to piece rates. In 1919 – the year of his death – he published ‘Organising for Work’. This marked an early contribution to the field we would now refer to a Corporate and Social Responsibility (CSR).

Gantt’s Ideas

We can summarise Gantt’s management thinking under three headings: incentivisation, task management, and corporate responsibility.

Workers’ Incentives

Taylor’s approach to incentivising workers was the piece rate system – getting paid only for the work you do. Gantt moved away from this idea, noting that motivation works best when you reward good work, rather than punishing poor work. So Gantt’s approach was to offer a base wage, with bonuses to workers who performed beyond a certain level. This meant that workers in the learning stages of their roles could earn a decent wage and led to a doubling of production levels.

He went on to provide additional incentives, most notably to foremen. This would recognise the collective efficiency of a work team and provided encouragement for on-the-job training. Gantt had clearly departed a long way from Taylor’s thinking, in the direction of humanistic management, when he wrote in ‘Work, Wages and Profits’:

‘the general policy of the past has been to drive; but the era of force must give way to that of knowledge, and the policy of the future will be to teach and lead, to the advantage of all concerned.’

Gantt was a close contemporary of Mary Parker Follett, with whose thinking this aligns, but I can find no reference suggesting that they knew one another. He was, however, a good friend of Frank and Lillian Gilbreth.

Corporate Responsibility

In ‘Organising for Work’, Gantt set out an agenda for corporate responsibility to society. He argued that the cold ‘buy low: sell high’ approach to business would not meet the challenges of business leadership in the twentieth century. He placed far more emphasis on the role of executives in motivation and efficiency that did Taylor – who saw workers largely as automata.

As he distanced himself from Taylor, he held that businesses have a duty to serve their communities, using the phrase ‘social responsibility’.

Task Management

There is no doubt, however, that Gantt is best remembered (only remembered?) for the Gantt Chart. This is a representation of tasks as bars on a chart that plots a list of tasks down the left hand side and sets a time line from left to right. Each task is shown as a bar. The length of the bar represents the duration of the task, and the placing represents its scheduling. Shading of the bar can represent levels of completion.

This was one of many different charts that Gantt developed, to help make work easier to plan and manage. This was him at his most ‘scientific’.  In his early career, he said that scientific analysis is the only route to industrial effectiveness.

So, did Henry Gantt invent the Gantt Chart?

We will never know if he was aware or not (I suspect not) but the same chart had indeed been ‘invented’ in 1896 by Karol Adamiecki. Adamiecki was a Polish economist and engineer, whose misfortune, if you like, was to publish in Polish and Russian. So, his writings received little attention outside of those countries and we now have the Gantt Chart, rather than the Harmonograph (Adamiecki’s favoured name) or the Adamiecki Chart. It is not clear to me when Adamiecki’s work was available – references I can find suggest he only published in 1931.

Who cares?

Apart from pride of authorship (among two long dead men) or nationalistic pride (between Poland and the US), there is little value in worrying who invented it. I’d be prepared to bet that if we had marks in the sand preserved from the ancient builders of Egypt, Sumer, Meso-America, Cambodia… somewhere we’d find a bar chart scratched out hundreds or thousands of years ago. What matters is the phenomenally wide usage this chart has.

The Gantt Chart is seen as a cornerstone of modern project management, yet it is hard to imagine the impact it had in the 1920s and 1930s, on US industry and Soviet Union central planning. And it has barely changed in the last 100 years. The only real difference is the technology we use to produce the charts and the consequent ease we have in using them to drive calculations.

For this, Henry Gantt does deserve to be remembered. So to, though, does Karel Adamiecki.

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:
Posted on

The Critical Path

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.

One of the pieces of project jargon that causes most confusion is ‘Critical Path’ and ‘Critical Path Analysis’, the process of calculating the critical path. The concept is actually quite simple, providing you start at the beginning.

Tasks, Duration and Sequence

The first step in preparing a project plan is to identify all of the tasks you will need to complete. When you have done this, for each task, you must estimate how long it will take. The third key step is to figure out how the tasks connect up, logically, into a sequence. For most of them, one task will be followed by another, which will be followed by another. In project management jargon, this is a series of ’finish-to-start dependencies’. This sequence creates what is known as a ‘work stream’. The complications arise when some tasks can run in parallel to one-another, when some tasks can trigger the start of more than one task, and when some tasks can only start when more than one task has finished. There are more complications than this, but that’s enough and covers most small to medium sized projects! The best way to make sense of all of this is to draw yourself a flow chart; what is known as a ‘network diagram’. Network Diagram

Calculate the Critical Path

Once you have the logic of your network drawn out, you can add your estimates of the durations of each task. These will allow you to calculate how long each path through the network will take. The longest path is called the ‘Critical Path’. It is critical because any delay (or ‘slippage’) to a task on that path will cause a delay in the completion of your project. Critical Path on a Network Diagram There you have it – simple in concept. Of course, like much that is simple, in the real world it is seldom easy. Calculating (and optimising) the critical path for a large, complex project with very many interdependent tasks is a big computation. When the methodology was invented in the 1950s, it was a big job to undertake. Nowadays, all but the very the biggest projects can be planned, optimised and monitored with the help of software running on a standard personal computer. I will never forget having the chance to look through the network diagram of the project to build and launch the first NASA Space Shuttle. Hundreds of pages of large paper and small print. ‘But’ said the project manager who showed me it, ‘when they planned the Mercury and Gemini missions in the 1950s, every time an engineer or project manager wanted to change the logical sequence, the network (or a chunk of it) had to be re-drawn by hand.’ How would that affect our attitude to getting it right the first time?
Further Reading  From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this:
Posted on

Stakeholder 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 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 Stakeholder Management Process

Stakeholder management starts during scoping, to understand their varying needs and wants, and negotiate with them  to balance stakeholders’ long shopping lists with your constrained resources. In the planning stage, you need to figure out how to win over – or at least pacify – the doubters and keep your supporters happy, so that throughout this stage and the implementation stage, you can engage with your stakeholders actively. In the evaluation stage you will need their perceptions if you want to create a full assessment of your project.

The broad process for managing stakeholders has four steps.

Stakeholder Management Process

Stakeholder Plan

Build your plan for each stakeholder, based on your assessment of:

  • what they want from you
  • what you want from them
  • what level of influence and power they have
  • how supportive or sceptical they are
  • … and any other factors

Your plan should contain:

  • The messages you want to communicate
  • The means by which you plan to communicate them
  • What attitude to take (for example: consultative, informing, instructing, requesting…)
  • The best time to deliver each message
  • Who will be responsible for preparing and delivering each message
  • How you will test whether the message has gone down as you intended
  • How you will gather feedback from the stakeholder

Stakeholders are vital to your project. It is they, after all, who will pass the final verdict on whether it has a success…

or a failure.

Further Reading 

From the Management Pocketbooks series:

  1. Project Management Pocketbook
  2. The Influencing Pocketbook
  3. Handling Resistance Pocketbook
Share this:
Posted on

The Triple Constraint

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.

Defining a Project

We define a project in terms of its purpose, goal, objectives and scope.

  • Purpose: why we need it
  • Goal: what it needs to achieve
  • Objectives: the constraints we must meet
  • Scope: The breadth and depth of the work to be done

Objectives come in Three Flavours

Objectives set constraints we must meet: time, cost and quality parameters that define our priorities. Once all of these are fixed, we can think of them as occupying three corners of a rigid triangle: the time-cost-quality triangle.

The Triple Constraint - The Time-Cost-Quality Triangle - The Iron Triangle - The Triangle of Balance

This is also known by other names, the most useful of which is the Triple Constraint. Because once you have a plan, any attempt to change one corner…

  • to reduce the cost
  • to speed up delivery
  • to improve performance

… will only be possible if you are prepared to compromise one or both of the other two corners.

The important thing about the Triple Constraint is that it never tells you what to do – your primary and secondary time, cost or quality objectives must be your guides. But it will always show you clearly what your choices are.

An example…

You want your IT system to produce management data more quickly than it is specified to? Well that is okay. It can, as long as you are prepared to either:

  • Compromise on budget, spending more on the system and on the people and systems that feed it with data  –  or
  • Compromise on performance and accept either a reduced data set focused on the most important figures, or reduced data quality, giving first estimates only, based on the most material information, but awaiting the precision of the full information.

This is just an illustration, but it shows clearly how the Triple Constraint offers us options.

Further Reading 

From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this:
Posted on

Project Lifecycle

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.

Implementing business strategy usually means starting one or more projects. Whilst nothing would please me more (as a former professional project manager) than to devote a series of blogs to a thorough description of project management, that is not the role of these blogs and also, The Project Management Pocketbook already covers that ground.

So I shall limit myself, in the next few blogs, to some of the essential models that a project manager will need. We will cover:

Once the dates are passed, these links will work.

Four Stage Project

There are as many ways of representing the lifecycle of a project as project managers, but they all contain many of the same features, just different language for the stages, different choices of how detailed to be, and different graphical metaphors for how to draw it.

Here, we will use the version in the Project Management Pocketbook.

Project Lifecycle


Define the purpose, aim, objectives and scope of the project to evaluate whether it makes good business sense and is therefore worth proceeding to the planning stage. Good business sense here means consistency with your organisation’s mission, vision and values, and a reasonable expectation that the benefits will exceed the costs.


Put together a detailed specification for what your project will produce and then use this as the basis to plan what you need to do, in what order, at what time, with what resources and allocating work to which people. Calculate the cost of your plan to create a budget and compare that with the benefits you will get if your project delivers to its specification and you can create a business case. You business case will guide your decision whether to invest in implementing your project.


Now deliver your project, constantly monitoring for risks, changes, delays, overspends and the quality of your delivered products. Intervene where necessary to maintain control. At the end of the implementing stage, you can hand over the last of the things you have created to your customer, boss or client. Will they accept them? Only if they are fit for purpose.


How did it go? What did you learn? How did team members perform? Was it all worthwhile? Take this new knowledge into your next project and do that one even better.

Further Reading 

From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this: