Project Management – Not Just for Builders and Engineers

A beginners introduction to project management, whatever your industry or sector.

There was a time when project management was a technique, used almost uniquely for the engineering world.  However in recent years more and more organisations have recognised the value of project management in their operation regardless of their industry/sector/specialism, and increasingly they are adopting a Project Management Way of Working, or as we call it PMWoW.
PM Sectors PMAdvisor
There are realistically 3 main types of project, described below.  To many organisations all three have their place, and to others maybe just one or two.

Type One – New Product Development Projects

Traditionally project management techniques were applied to the first type of project – new products.  Those “products” might have been as diverse as bridges, buildings, new computer systems or cars.

Type Two – Customer / Service Delivery Projects

This was followed by the general realisation that the techniques and discipline could be expanded to the second type of project which we describe as “customer projects”.  Again, initially rooted in the engineering world, this sees the scope expanded beyond development to manufacturing, test, site deployment, acceptance, and broader service provision.

Type Three – Organisational Change

As the project management techniques and systems matured, they became increasingly used in the controlled delivery of organisational and strategic change.

Industry Shifts

The general project types are largely unchanged in the 21st century, but we have seen 3 major industry shifts in the last few decades:

1) Methodologies & Frameworks

As project management usage grew, so did the available methods.  From the original “waterfall” methods we have seen the steady addition of options including:
as well as a whole host of niche and bespoke methods.  Some of these methods are generally applicable, whereas others are only suitable in certain applications.
Some care should be taken when considering the latest “new” way of managing projects.  As with the world of diets, various fads come and go as people look for that easy fix.  However it is worth remembering that the core project management techniques are flexible, and if applied consistently can produce excellent success rates.

2) Technology

There has been a huge proliferation of project management tools with varying degrees of complexity and suitability for certain project environments.  I am aware of well over 250 software tools which can be broadly categorised as:
  • Productivity Tools which typically focus on individual or group task management,
  • Project Collaboration Tools which typically add messaging, file sharing, project calendars and maybe some bells and whistles,
  • All-in-one Tools (often referred to as P3), which add layers of complexity typically including planning, resourcing, RAID management and even portfolio/program dimensions, and finally
  • Specialist Tools which deal with specific needs such as risk management, mind-mapping, and so on.

3) Broader Industry Adoption

In the last few years, project management has become increasingly adopted across most industries and sectors.  Typically, this has initially filtered from new product development and strategic / change projects into service delivery with noticeable recent adoption in the worlds of service, marketing, human resources, digital marketing and legal to name but a few.

Where Do Budding Project Managers Go For Advice?

There are lots of resources around, but as in many walks of life you need to know where to look.  Some great starting points include:
At ProjExc we recognised that finding good, honest, independent advice, especially those entering project management, can be quite challenging.  We noticed though that everyone seems to be selling their training courses, their qualifications, their books, their tools.  We have structured our advice and services into 2 distinct but closely linked independent offerings, both of which are applicable regardless of your industry or sector:
PM Advisor – advice and resources for individual project managers, and
ProjExc – guidance, advice and support for organisations wanting to set-up or improve their project management capability.
About the Author:
John Williams is a project management professional with 25 years experience across most industries and most types of project, portfolio and programs.  He is founder of ProjExc and PM Advisor, an active author, presenter, and consultant on the subject of project management, as well as an occasional interim project manager.  John is a proud member of the APM and also serves in their volunteer community.  If you would like John to present his talk “Why Projects Fail and What YOU Can Do About It” to your team or group either in person or as an online seminar get in touch.

New Open Source P3 Framework Launches – Praxis

Praxis Logo

New Open Source Framework

Praxis, a new free framework for the management of projects, programmes and portfolios (P3), has launched today 1st May 2014.

According to their website “Praxis is entirely free to use under the terms of the Creative Commons licence. You may adapt and use the Praxis Framework for your own purposes as long as you acknowledge its source. You must also make your work available to others free of royalties. Ideally, your contribution will be incorporated into this web site for the benefit of others”.
The site further explains that “Praxis brings together a body of knowledge, methodology, competence framework and capability maturity model in a single integrated framework with a single structure and terminology. No more need for mapping and translation between different guides”.  The Framework encourages a practical application of the elements relevant to the environment.

Community Driven

There is an interesting angle to this new approach.  The Framework is community driven, Praxis stating “Most project, programme and portfolio management guides are updated by panels of experts every few years. Our aim with Praxis is to update and extend the framework and library on a continuous basis. As our users provide adaptations and lessons learned, we will incorporate these into the framework.”
So what (or who) is behind Praxis.  Paul Naybour over at Project Accelerator News reports that “The framework has been created by Adrian Dooley, an Honorary Fellow of the Association for Project Management who has ensured that the framework is compatible with widely known guides such as the APM Body of Knowledge, PRINCE2® and ISO21500.
Adrian said “I think it is time that the basic principles of project, programme and portfolio management were available to the ‘wikipedia generation’. I hope that experienced practitioners will tailor the framework and offer their adapted material for inclusion in the framework, thus helping the next generation of P3 managers.””


We’re intrigued by the Wikipedia (non-profit) suggestion.  Mr. Dooley has an impressive track record in commercialising P3 management.  He founded and sold TPG (The Projects Group), helped author Pertmaster, was a founder member of Project Manager Today, and is a non-executive director of APM Group Ltd which made a lucrative industry from managing qualifications for OGC (now the Cabinet Office) amongst others.  It will be interesting to see how Mr Dooley and Praxis Framework Limited plan to monetise Praxis, or whether indeed this is a non-profit enterprise for the benefit of the profession.

Defining Project Requirements

It is unsurprisingly difficult to meet with customer or user expectations without a clear definition of requirements agreed at the beginning of a project. Unfortunately, too many customers are unable or unwilling to commit to requirements. Similarly, too many project managers fail to put sufficient focus on finalising their agreement swiftly enough. The requirements form the basis of a detailed project management plan. Sadly too many projects fail as a result of the resulting ambiguity.

Very often, the main cause for failing to define requirements adequately is insufficient understanding of, or confidence in, the techniques and tools needed to appropriately capture the essential project requirements.

A practical, nine-step process for defining requirements for your project or product is suggested in the book “Customer-Centered Products” by Ivy Hooks and Kristin Farry:

  1. Scope the project or product by defining needs, goals and objectives, outcomes, mission or business case, high-level operational concepts, customer requirements, constraints, assumptions, schedules, budgets, roles and responsibilities.
  2. Develop operational concepts – scenarios for how your project or product might be used by the end user. Expand the concepts to cover all phases of the product or project life cycle.
  3. Identify interfaces between your project or product and the rest of the world, clarifying boundaries, inputs, and outputs.
  4. Write requirements to guide product design toward what your customers need and want.
  5. Capture rationale (the reasons for the requirement’s existence) behind each requirement and expose potentially dangerous assumptions and incorrect facts.
  6. Level requirements according to system and system sub-divisions, ensuring that all requirements are written at the right level and can be traced back to their origins.
  7. Assess verification of each requirement, identifying the verification technique and facilities and equipment required.
  8. Format requirements and supporting documentation to ensure that you have included each of the appropriate types of requirements and that your development team members can find all of the requirements they must meet.
  9. Baseline requirements after validating that they are correct, complete, consistent, meet the project scope, and do not add unnecessary functionality or features not covered by the original scope.

Gathering RequirementsGATHERING
There are several techniques for initially gathering (elicitation) of the requirements. The following Top10 from TechRepublic provides for a thorough capture.

#1: One-on-one interviews
The most common technique for gathering requirements is to sit down with the clients and ask them what they need. The discussion should be planned out ahead of time based on the type of requirements you’re looking for. There are many good ways to plan the interview, but generally you want to ask open-ended questions to get the interviewee to start talking and then ask probing questions to uncover requirements.

#2: Group interviews
Group interviews are similar to the one-on-one interview, except that more than one person is being interviewed — usually two to four. These interviews work well when everyone is at the same level or has the same role. Group interviews require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused.

#3: Facilitated sessions
In a facilitated session, you bring a larger group (five or more) together for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately.

#4: Joint application development (JAD)
JAD sessions are similar to general facilitated sessions. However, the group typically stays in the session until the session objectives are completed. For a requirements JAD session, the participants stay in session until a complete set of requirements is documented and agreed to.

#5: Questionnaires
Questionnaires are much more informal, and they are good tools to gather requirements from stakeholders in remote locations or those who will have only minor input into the overall requirements. Questionnaires can also be used when you have to gather input from dozens, hundreds, or thousands of people.

#6: Prototyping
Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements that you use to build an initial version of the solution — a prototype. You show this to the client, who then gives you additional requirements. You change the application and cycle around with the client again. This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations.

#7: Use cases
Use cases are basically stories that describe how discrete processes work. The stories include people (actors) and describe how the solution works from a user perspective. Use cases may be easier for the users to articulate, although the use cases may need to be distilled later into the more specific detailed requirements.

#8: Following people around
This technique is especially helpful when gathering information on current processes. You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. You may need to watch them perform their job before you can understand the entire picture. In some cases, you might also want to participate in the actual work process to get a hands-on feel for how the business function works today.

#9: Request for proposals (RFPs)
If you are a vendor, you may receive requirements through an RFP. This list of requirements is there for you to compare against your own capabilities to determine how close a match you are to the client’s needs.

#10: Brainstorming
On some projects, the requirements are not “uncovered” as much as they are “discovered.” In other words, the solution is brand new and needs to be created as a set of ideas that people can agree to. In this type of project, simple brainstorming may be the starting point. The appropriate subject matter experts get into a room and start creatively brainstorming what the solution might look like. After all the ideas are generated, the participants prioritize the ones they think are the best for this solution. The resulting consensus of best ideas is used for the initial requirements.

There are numerous templates freely available.  We touch on project tools more here.

Often there is a temptation to use specific software for capturing requirements, and there are numerous commercial offerings to meet that ’need’, however it is worth bearing in mind that basic office tools are often just as effective.

Project Management News Digest w41 2013

NewsDigestProject Management Frameworks for SMEs

Project Accelerator

More and more organisations are looking for a Framework for successful project management, and for SMEs PRINCE2 can be overkill.

Handbook of People in Project Management

A new PM book by Dennis Lock and Lindsay Scott looking at one of (and probably the most important) the 3 elements for project success – people.

UK Economy Strengthening – Signs in the Projects World

Two of the biggest indicators that the UK economy seems finally to be turning the corner to us here are:
  1. There is a steadily increasing number of PM jobs being advertised, and
  2. There are more people talking to us about now being the time to take the plunge in that big project, where would they find a good PM, and how would be the best way to apply appropriate governance to the project.
Both suggest that projects are being started, and we all know that projects are huge investments.

Flow Upgrades to Full PM Suite

The web and iOS tool has been updated with additional team functionalities.

The Power of Project Governance

An interesting insight and useful checklist from Anita Potgieter.  We’re not sure that the only project management system is Project Server 2013 though!

APM Launches The PM Channel

A great online resource with on demand PM training & development

Glossary of IT PM Terms You Should Know


Wrike Raises $10m from Bain Capital for PM Tools


New Infographic Shows the Need for a PMO

The Intersect Group

5 Mistakes You Don’t Want To Make As A PM

  1. Omission of milestones
  2. Disregarding your risk log
  3. Failing to communicate
  4. Losing sight of the big picture
  5. Not updating your calendar
5 Best Personal PM Tools
Lifehacker recently asked their readers to describe their best personal project management tool.  The top 5 were.  Some interesting surprises there..
  1. Asana
  2. Troll
  3. Microsoft OneNote
  4. Evernote
  5. Azendoo
5 Best PM Techniques to Steal
  1. Kanban
  2. Scrum
  3. GTD
  4. CCPM
  5. Kaizen
Popular iOS Mindmapping Tool iThoughts Now On OSX

Did we miss something?  Let us know.

Critical Chain Project Management

iStock_000018782205SmallPM Advisor and our consultants at ProjExc are constantly looking for ways to help Project Managers to be more successful, in what we call the Post-PRINCE era of project management.

One “new” methodology that has been growing in popularity for a few years now, albeit mostly under the radar, is Critical Chain Project Management, or CCPM. CCPM is based on the ideas presented by Eliyahu Goldratt in his books The Goal and Theory of Constraints.

CCPM promises the successful delivery of projects significantly earlier, with more confidence and using less resources. The cost for this is a huge leap of faith, and the need to get every department involved in a project (from executives to manufacturing and sales) completely engaged and committed to the concept from the outset and to keep that faith to the end!
That said, a growing number of big organisations are adopting CCPM having recognised a significant opportunity to compete. For example, only yesterday, we read in Business Insider that the 3 books which Amazon CEO Jeff Bezos asks his senior managers to read includes Goldratt’s The Goal.

We have read the books, done the research, and seen, heard and read about a number of success stories, as well as one or two horror stories of implementations gone wrong. It was fascinating therefore to get an opportunity at a recent APM event (The Real Reason that Projects Fail & How to Fix it) to hear from Gary Palmer of Critical Point Consulting, a CCPM consultancy from Kent, explaining the differences between traditional PM methods and CCPM. Clearly a convert to the “teachings” of Goldratt et al, Gary passionately believes that the only way to make projects successful is to adopt the principles and methods of CCPM.

Interestingly, and regardless of views on the suitability of CCPM, we wholeheartedly agree with Critical Point that project objective failure rates of 66%+ are unacceptable, leading to unnecessary disappointment, frustration, poor productivity, late market entry and impact on the bottom line. Liberal application of common sense together with a pragmatic implementation of waterfall, agile or a combination can make a huge difference to success.

What is CCPM?
Palmer sees this as a set of interlinked techniques & tools that work individually and collaboratively to significantly improve the processes and operation of scheduling & execution in projects, portfolios and programmes alike. The key to CCPM is scoping and scheduling. As the project proceeds the main role of the project manager is to ensure that the focus of the whole organisation is to ensure that potential critical/key resource constraints are always avoided at all costs.

The main observed problems in traditional PM:
1. Deadline driven scheduling feeds the impact of Parkinson’s Law meaning that early finishes never materialise,
2. Task level contingencies tend to have a product rather than summing effect, leading to resources adopting student syndrome and having no incentive to start early.
3. Critical Path focus completely ignores resources when planning resulting in frequent changes to the plans.
4. Multi tasking slows everything down, reduces quality and destroys productivity.
5. Poor measures & control tend to only focus on %age complete reported to expectation, and spend to date and subjective retrospective opinions of progress. However does the PM really have objective data to understand is the project on target?

CCPM solves these problems, in turn, by:
1. Creating a dependency “relay race” with no dates in the schedule.
2. Placing a total project “buffer” to be shared by all resources at end of the schedule, before an agreed project “commit” date, thus aggregating uncertainties.
3. Focus on the Critical Chain including resources. This forms resource dependencies rather than task dependency.
4. Single Tasking. Only one task is worked on in the chain, with no interruptions and dedicated resource until complete.
5. Good measures & visible control. Daily reporting of whether a task is complete, or if not how much task time remains. This is reflected in a Fever Chart.

Two other major benefits.
1. CCPM removes the need for schedule changes greatly simplifying life for the project manager, and
2. Each individual problem encountered no longer perpetuates others.

There is a small but growing pool of critical chain project management software meeting the needs of the new market. Some are standalone, some are add-ons to traditional tools like MS Project and additionally some of the all-in-one tools are integrating CCPM. These include:

The key management tool which is easily adopted and communicated is the Fever Chart. This powerfully visualises how much of the critical chain completed, and how much of the buffer has been consumed, and the PM would generally share this with the whole team on a daily basis.

Other Useful Links and Related Resources
Goldratt Books on Amazon.
Kelvin Youngman’s A Guide to Implementing the Theory of Constraints is a super guide with many useful resources.
The Billion Dollar Solution, Robert Newbold’s secrets of ProChain Project Management.
UK Goldratt Consultancy.