Before we dive into the philosophy of project management, I would first like to define philosophy and methodology as people often confuse the two:
What is philosophy?
Wikipedia says, Philosophy is the study of general and fundamental questions, such as those about existence, reason, knowledge, values, mind, and language. Such questions are often posed as problems to be studied or resolved.
My summary of Philosophy could be boiled down to one word, Why. It is the questioning of the fundamental reasons for something.
What is a methodology?
Methodology is the study of research methods, or, more formally, “‘a contextual framework’ for research, a coherent and logical scheme based on views, beliefs, and values, that guides the choices researchers [or other users] make”
My summary of methodology then is a framework or set of rules or tools which can be applied by a user to solve a problem. In our case, a set of rules which could be followed by a project manager.
The origin of the Projects?
The word project comes from the Latin word projectum from the Latin verb proicere, “before an action” which in turn comes from pro-, which denotes precedence, something that comes before something else in time (paralleling the Greek πρό) and iacere, “to do”. The word “project” thus originally meant “before an action”.
When the English language initially adopted the word, it referred to a plan of something, not to the act of actually carrying this plan out. Something performed in accordance with a project became known as an “object”. Every project has certain phases of development.
Based on the Project Management Institute (PMI), a project can be defined as a “temporary endeavour” aimed to drive changes in teams, organizations, or societies. The output of a project is normally a unique product, service, or result.
What is the project management philosophy?
As a project manager you seldom stop long enough to think how to take a philosophical approach to project management, but going back to basics is useful for even the most experienced of project managers from time to time. Normally we just look at the type of project we have been asked to manage and then follow a suitable project methodology such as PRINCE2 or Agile Scrum.
It is important to differentiate between Projects and Business as Usual (BaU) Operations. A project has a defined scope in terms of what change is to be made or what thing is to be built or developed when it needs to be done and the budget that can be spent to achieve this outcome.
If someone talks about ongoing work, consider this a red flag. Any task which is ongoing indicates a BaU activity rather than a project activity.
We can contrast Projects with Business-as-Usual Operations which have no set start or end date and are only expected to follow a regular and unchanging process or procedure. A production line in a factory which makes chocolate biscuits would be considered business as usual operations. Operations Management of these BaU activities is itself a specialist area but quite distinct from Project Management.
On the other hand, if a new production line is to be installed by Christmas to double the output of chocolate biscuits for the festive season, then that is a project as it clearly has a defined scope and timescale and no doubt the business will have established a budget for the new production line as part of their business case for the project.
From what I can tell Project Management as we would recognise it today didn’t start until the early 1900’s. Henry Gantt developed his Gantt Chart to help manage supply line projects during the first World War. After that major projects like the Hoover Dam, the Manhattan Project and NASA and the space race, all aided by rapid developments in technology such as photocopying, computers and the early Internet rapidly drove the development of Project Management as a management discipline.
Prior to 1900’s Projects were mostly Construction projects in one way or another or otherwise small endeavours.
How would you build a railway line across the country without formal project management as we know it today? Little seems to have been written on how Telford, Stephenson and Isambard Kingdom Brunel managed their ‘projects’. It would make an interesting area for further historical research.
Project Management Philosophy: Vision or common goal
The first key aspect to Project Management Philosophy is a simple, easily explained, easily communicated vision which investors and workers can understand, back and imagine what the end goal will look like.
The project vision or common goal is the foundation on which all successful projects are built. I advise leaders who are struggling with the vision or goal to sit down and draft the press release they would like to be able to issue upon completion of the project.
Since the 1960’s catchy mission statements have become popular. First, we had John F. Kennedy and “We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win, and the others, too”.
A few years later Captain James T Kirk said “Space: the final frontier. These are the voyages of the starship Enterprise. Its five-year mission: to explore strange new worlds. To seek out new life and new civilizations. To boldly go where no man has gone before!” at the start of every episode of Star Trek. It is thought that the modern drive for ‘mission statements’ was heavily influenced by this.
Since then, every successful organisation and project has had a mission or vision statement. Generally, the shorter the better. You will often hear people talking about an elevator pitch. This is the same concept. A message or vision is so clear and concise that it can be communicated in the seconds it takes to travel between floors and so compelling that it will be retained by the recipient as they go about their day.
Most project management methodologies and frameworks recognise the need for this vision statement or mission statement. It will normally be written pre-project and incorporated into a project charter document.
If your vision statement is clear and compelling enough to fire up the imagination and drive of investors, workers and other stakeholders the project will almost deliver itself. Words are incredibly powerful and can do the work of thousands of people. Good businesspeople and project managers understand this and would rather delay the launch of a project than to try and get started with a underwhelming vision statement. Invest the time, resources and energy in getting this right.
Looking back pre-1900, inventors such as Isambard Kingdom Brunel had crystal clear vision statements. They also had architectural and engineering plans to show what was to be built. In a time before email and telephone work had to happen over large distances and by lots of people. Once the vision had been communicated, specialists or trades could be brought in to do their piece of the build.
It is easier to share a vision with small teams and easier to carry out small projects. This observation has led to Agile Scrum teams which are usually about seven people and Programme Management, where a strategy is delivered through a set of small individual Projects and manageable, lower-risk projects which deliver value faster than one single massive multifaceted project. Programme Management then seeks to manage a portfolio of projects to deliver the strategic objectives of the business.
I and many other Project Managers advise against having large teams. Jeff Bezos the founder of Amazon famously said never have more people in a meeting than you can feed with two pizzas. For me, the maximum is 7 to 10 people. Teams with more than 10 people should be considered a red flag. If you look further at Amazon, what you find is not one single large business.
The Amazon business has been carefully structured into vertical sectors and then further broken down by geographical region. Essentially decomposing the impossible task of managing such a big multinational company into small human scale, manageable tasks. It’s also interesting to note that a by-product of this approach is the ability to benchmark teams doing the same or similar work. This allows Amazon to take a data-driven analytics approach to identify outliers both above and below the norm and to then learn from what is working in high performing teams and then scale this out as best practice globally.
How project managers form and communicate the shared vision is subject to continuous improvement.
Small projects are beautiful projects
As we have seen above large project teams are to be avoided if possible. Likewise, large projects should be avoided or rather engineered into a series of small projects. Small projects lasting a few weeks or months are more likely to be successful and return value to an organisation that a big project that takes a year or more to complete.
Financially it is worth considering that a small project starts to payback as soon as it is done, so depending on phasing, can be more valuable than a large project which pays back big but late.
Consider a project that when complete will generate an additional £10,000 of sales per month. It takes 2 months to complete and gets started in January. This means that for the period March to December it will generate 10 * £10,000, so £100,000 of incremental sales. Now think about a large project which is going to take a year to complete but which will then generate £100,000 of incremental sales per year. Which project would you rather back?
Even if both projects cost the same to execute, which they won’t, keep in mind small projects tend to be lower risk and more successful. The probability then is that the small project will deliver more value than the big project and sooner.
If a small project runs into difficulties and takes twice as long to complete as expected, you will still get a good return within the year. On the other hand, if a 12-month project starts to slip and takes twice as long to deliver it will be much longer before you see any benefit.
Knowing when to cancel a project
In my experience, from time-to-time projects do hit problems. When this happens the project manager along with a steering group and the project sponsor(s) have to decide if they want to extend the time and cost of the project and work through the problems or pull the plug on the project and terminate it early.
Understanding that a project is failing and should be cancelled is one of the hardest leadership skills to master. The project team members will more often than not be keen to complete what they have started. At this point, an experienced manager will need to carefully balance the risks.
It is better to cancel a project early than to push ahead and then cancel it late. This brings me back to the benefits of small projects. They are less likely to run into difficulties because they tend to be small enough for people to be able to visualise their way through to delivery and identify potential blockers at a pre-project stage. However, if you do have a problem in a small project where the costs involved are smaller it is much easier to cancel it. Would you rather cancel a small project after incurring £8,000 of cost or a large project after incurring £800,000?
The agile project management methodology accommodates small is beautiful through breaking projects down into epics and user stories. The Agile manifesto includes “Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.”
Project Management Philosophy: Route Map
Having established a vision for the project we then need a route map. This needs to breakdown the work into manageable work packages and place them into a logic chronological order. Having a route map helps to make sure that everyone is going in the right direction and at the right time. This may sound easy but project managers have to struggle with this type of thing all the time. Even with something as routine as building a house, ensuring the trades all turn up in the right order still goes wrong from time to time.
The Route Map can take various forms. It can be highly detailed as would be the case with the PRINCE 2 project methodology. This would see us having details work packages and Gantt charts and the project following what has become known as the waterfall model. This traditional approach is still ideal and recommended for many projects. For other projects, it may be better to follow the Agile approach. This would see us layout the route map in the form of Epics, Features and User Stories delivered in phases known as sprints. The key difference is that the Epics layout a high-level route map of what is needed but doesn’t prescribe how the work is to be done. The detailed design, planning and implementation is done by the sprint team(s) in timeboxed sprints. If you would like to know more about the Agile Method I have written a number of articles about this which will be of interest to you.
When developing the route map there will be a number of key tasks which need to happen in a certain sequence, and which cannot overlap. These form what is known as the critical path through the project. If any of these tasks slip the project will be delivered late unless time can be made up on a later task on the critical path. Tasks on the critical path can be contrasted with tasks which are not on the critical path where the project manager has more scope to sequence or delay tasks without impacting the end date.
Change Management or Change Prevention
We’ve set out with a well-crafted vision and then developed a route map to show how the vision can be delivered. Part way through the journey someone thinks of an additional requirement or changes one of the requirements. What do you do?
In my experience most project managers and even software development managers don’t like change and will do their best to prevent it. You may be aware of the saying “Change is the only constant” and this is very true.
One of the basics of project management has to therefore be a willingness to handle change efficiently rather than avoid it. Project sponsors are customers of project delivery teams and we should be customer-centric as far as possible. Experienced project managers will however tell you that sometimes you just have to protect the client/sponsor from themselves. Some clients don’t understand that if they keep changing requirements it will make the delivery in efficient and drive up the cost and push out the delivery date. So there is a balance that needs to be found and usually best handled through educating the client and ensuring they understand and sign off on the implications of changes they want to make. Most methodologies will have the concept of a Change Control Request or CR for short.
Project Management Philosophy: Risk
Once everyone is clear about what the project is to deliver, the role of Project Management is to ensure a successful outcome. Projects are normally constrained by time, cost and quality parameters. The project manager has to try and balance these, staying within any two of these is relatively easy but doing all three needs more skill. For example, we can stay under budget and deliver early but in that case quality will likely suffer.
There are many things which can go wrong in projects which can affect the project schedule, cost or quality of the deliverables. Thankfully these days we have a project management body of knowledge which details best practices. There is now a well-established set of principles for risk management. These will include the creation of risk registers to identify likely risks and risk mitigations strategies to proactively reduce the likelihood of a risk happening. There will also be contingency planning should a risk become a real event.
Most true projects are novel in some way, that is, they are seeking to build or do something which hasn’t been done before, or at least not by the project team. Doing anything for the first time carries the inherent risk of the unknown and the unexpected.
Project Management is sometimes used to deliver standardised solutions such as the installation of a wind turbine. With repeatable processes like this, the risks are much lower, as after installing thousands of wind turbines or solar panels people have seen almost everything that can go wrong. Over time this experience is captured into checklists and implementation methodologies, various industry-standard approaches and even legal regulations.
The methodologies and contracts used in construction projects have come a long way since 1990’s. It is less common now to hear of constructions projects going significantly over budget or being delivered late; although we can all name exceptions.
In contrast to construction projects, software development is a risky business. Some investors try and avoid projects where any new software is being developed as there can be a high failure rate.
Project Management Philosophy: Efficiency
So now everyone is clear about what the project is to deliver, the high-level plan in the form of the route map and the risks have been identified and mitigated. Now the project management philosophy moves on to the next theme which is the efficiency of the project execution.
In business, if we execute a project perfectly on time and deliver outstanding quality but it costs five times more than similar projects carried out by competitors we will soon be out of business. There is a need to use our resources in the form of capital, labour and time efficiently.
Project management, therefore, has to include quality management and cost management. Both of these are specialist skills these days and there are qualifications and certifications for these in general and also in specific industry sectors. One such management approach is lean six sigma which seeks to identify and remove wasteful activity and expenditure.
Project Management Philosophy: Learning
As we have seen above the philosophy and art of project management have evolved greatly since 1900. Most methodologies involve a post-project review so that any learnings and recommendations from the project can be documented and incorporated into future projects. The Agile approach takes this a stage further and calls for a retrospective to be held at the end of each sprint. This seeks to identify what went well and what could be improved in the next sprint to increase efficiency and sprint capacity.
On a national and global basis project managers belong to professional bodies and attend conferences where they are able to share their experiences and knowledge. Over time the experiences get distilled and captured into the Project Management Book of Knowledge and updated to methodologies such as PRINCE 2.
Project Management Philosophy: Summary
This graphic shows the five essential project management principles. You will find these addressed in different ways by different project management frameworks and methodologies, but they will all have them in one form or another.The project starts with the formation of the
Vision: This stage can be expanded out to further articulate the major project requirements.
Roadmap: The chronological sequence in which the tasks need to be performed. This can be handled with a Gantt Chart but could also be handled with a kanban board or through high-level epics in development projects following the Agile process.
Risk Management: Attempts to identify risks, the probability of them happening and the impact. Usually, probability and Impact are plotted into a matrix to identify those sitting in the top quadrant which represents a high probability and high risk. The top-quadrant.
Within this article really just want to introduce Risk Management as an element of project management philosophy. I will be writing in detail on risk management in future articles.
The efficiency of delivery: Time, Cost and Quality management.
Learning: What lessons can be learnt from the project and taken forward into future projects to improve the process over time. At the centre of the diagram, we have placed quality.
Quality: While it can be argued that quality runs through all the activities, we could equally argue that this is a key feature of the principle of efficiency. A project which suffers from bad quality will have a high level of rework or will fail to deliver the vision. On balance, we have left it at the centre of the diagram because quality is so important to almost all projects. Few people would set out with a vision to create a low-quality outcome for example.
I have briefly mentioned software or IT development projects in passing but have tried to look at projects more broadly. I have talked about Agile a few times and it is worth mentioning that the Agile methodology can successfully be applied to many projects and it is not just limited to software development projects. Future articles will look at the Agile Manifesto and the Software Development Lifecycle (SDLC) in detail.