There are numerous books and guidance for building a good Work Breakdown Structure. But there is an underlying principle that guides, or should guide this effort. It is the MECE (Mutually Exclusive, Collectively Exhaustive).
Mutually Exclusive - no subcategory should represent any other subcategory ("no overlaps"). In the WBS this means the deliverables are unique so we can assign cost to them and determine who is going to develop them.
Collectively Exhaustive - the set of all subcategories, taken together, should fully characterize the larger category of which the data are part ("no gaps"). The WBS represents the "all in"work. If it's not in the WBS, it's going to get done.
Building a good WBS, does not start with defining the level of the WBS it starts with the MECE principle and the resulting product (or service) architecture. Now the architecture of the product or service is developed by a systems approach, WBS building is systems architecture, for several reasons:
- We need to know the components of the system that are ME (Mutually Exclusive).
- The children of these components must be CE (collectively exhaustive). Parts can be shared in the WBS, if the work for those parts can be shared, but they need to have different WBS numbers, so they are ME, while being CE.
- Then the WBS can be used to collect costs and answer the question, "what does this part, sub-assembly, assembly, system cost.
- The resources are then assigned (not named by categories if you can come to see that names change with change control, categories don't) and build the RAM (Responsibility Assignment Matrix) to see who is working on what, for what cost.
- That whole coding system is placed in the IMS in separate columns (WBS and maybe the CWBS) and Resource Category to show when the thing is being built, for what cost, and by what labor category.
Spencer Holmes of Project Leaders today introduces a new way of addressing project management development. His three key points are as follows:
- There is a leadership deficit in project management
- Why this might be
- The start of a training and development answer
This is the first in a series of eight articles in the weeks to come from Spencer on project leadership and development of project leaders. Be sure to check out the psychometric test link below that Spencer set up free for Camel users – seems I’ve got some project leadership “potential” myself!
Over to Spencer now…
Our story: In simple terms, too many Project Managers are struggling with leadership, whether it be managing stakeholder expectations, negotiating with suppliers and contractors or raising team morale when the project has gone off the rails.
Our team has been grappling with this realisation for seven years, combining university and industry research to boil down those few factors that differentiate project managers from project “leaders”. Before going into these, I’d like to take a moment to consider the issue.
As a jobbing PMs and PM trainers and consultants, we know this is an issue. Just check any discussion in a project management LinkedIn group and ALL the chat is about leadership. There is a real deficit of leadership behaviour on projects. I believe there are a number of factors at play here.
Often, PMs become PMs because they were good at something else, software development, quantity surveying, forestry, you name it. This comes about through a misguided, (although usually well-intentioned), belief that project management is a fair way of promoting a subject matter expert into a wider role. Project management is of course a huge change of scenery from being the specialist in a niche.
One of the best presentations on leadership I’ve ever seen is by Benjamin Zander, which can be viewed below. Please indulge when you have a spare 20 minutes or so.
The bit that really stayed with me was when he says that, as the conductor, he leads the orchestra but makes no noise. He positions leadership as coordination, guidance, a focal point, but not running round and trying to play all the instruments. Project leadership requires project managers to come out of the pit, and to keep everyone, players, composers and audience alike, delighted with what is going on. This is hard.
I also find that PMs are usually selected from the mid regions of the organisational structure yet the outcomes they need to achieve require the engagement of those higher in the food chain. When sponsorship is weak (which it so often is) PMs have little or no chance of influencing the right people in the ways they need to.
Lastly, projects are about “change”. Of course introducing change at almost any level creates a range of behavioural responses, not by any means all positive. It takes real leadership talent to deal with humans when they are expressing conscious and sub conscious resistance. All this also takes place in the pressure-cooker environment of balancing time, cost and quality parameters.
So, the result of our research has been to describe seven facets of personality that create the basis for effectively leading projects, the difference between project management and project leadership. These are the facets we need to understand in order to elevate the role into a significant change catalyst and leader of business progress.
The facets link closely with the “big five” personality traits, which have been updated and adjusted to reflect contemporary project leadership challenges.
So the 7 facets are:
- Pragmatism – goal-oriented, focused and determined completion of tasks
- Creativity – seeking novel solutions to old issues
- Positive intolerance – taking tough decisions to get projects achieved
- Stability – effective performance under pressure
- Communication – clear and effective articulation of any issue to any audience
- Motivation – of self an others in the project, especially when times get tough
- Group orientation – collaborating with others to improve project outcomes
Of course these headings can be, (and have been), deliberated and adjusted indefinitely. However we firmly believe, from our extensive review of 100 years of leadership literature and, possibly more tellingly, repeated consultation of industry leading Project Managers, and the refinement of that consultation, that these fit the current picture.
Both training and consulting on project matters, I know first hand that the behavioral side of the job is given a second class status in comparison to technical tools. (Even those are patchy at best). However, from my own background in rehabilitation, I have always contested that “soft skills” are always the hardest to improve and embed.
So I am using this blog to canvas opinion on the facets – your views as to their relevance and experiences of where they have been applied, or where a deficit in one or some have costed the project.
I will use my next 7 blogs to describe these facets in more detail.
Our test: At Global Project Leaders we have just released the third, improved version of a psychometric test to try and measure the results of our research and provide useful feedback for acting and potential project leaders. Usually $29, we would love you try this for free by going to www.thepsychometrictest.com and completing the full test. When you are asked to pay simply put in the following code 016d95e7d1 and you will soon receive a report on your project leadership profile.
Related Posts
- New Project Management Book Available for Review
- Tools and Psychological Tidbits for Stakeholder Engagement
- Don’t forget your soft skills!
- Project Management Leadership Competencies (PMLC)
- Book Review: The Lifelong Project
What makes a project successful? Emanuel Camilleri in the book Project Success: Critical Factors and Behaviours
The problem with a book on project success is that success means different things to different people. “[T]he perception of the stakeholders is fundamental to success,” Camilleri writes. He also points out the difference between project success (is the project a good thing) and project management success (was the project delivered in accordance to best practice). In order to address these, he has included bits of both in the book.
Project Success is based upon Camilleri’s literature research. He’s gone through academic papers since 1971 and looked at all the studies done into project success criteria. Then he has categorised them and ranked them by the number of times those criteria pop up in the research results. That gives us a list of the top things to work on to give ourselves a fighting chance of being successful. He writes:
“[T]he most important dimension for ensuring the successful implementation of projects, in order of priority, include:
- Project Planning and Control;
- Project Strategic Fit;
- Project Scope;
- Employee Commitment and Participation.”
These are the top four in a list of 11, and the rest of the book looks at each of them in turn.
The section on strategic fit is interesting. Whole books have been written about portfolio management and Camilleri has managed to squash project selection into 12 pages – and three of them are diagrams.
The book has plenty of diagrams, flow charts and even a scope definition template, but it still doesn’t feel like a practitioner’s book. For example, there are a few pages on assessing the project team environment and establishing whether it’s conducive to high performance. This is based on five measures:
- Level of role conflict and ambiguity within the project team
- Adequate definitions of roles and responsibilities
- Appropriate level of processes and procedures
- Level of collaboration within the team
- Level of cooperation between the project team and external stakeholders.
Each of these measures is the subject of a flow diagram. The flow diagrams provide a scoring system which ranks your project team. I can see the benefit of this for consultants, people joining a new company in roles where they can influence the outcome, or (maybe) new project managers joining a new team and who want to know what they have let themselves in for. But practical, day-to-day use? I don’t need to score the team environment. I live it – I already know.
In some areas the book is very detailed. For example, there is a good section on knowledge management and information flow. There’s a worked example of a project with start and end time constraints which explains float and resource levelling. But lessons learned is covered in just 5 lines.
One of the reasons I believe this is not a practitioner books is because it widely draws on management theory and is often concerned with the organisational layer, such as putting in place relocation and termination policies for employees. While you could have some influence at an individual level, this is not something most project managers can do.
To be fair to Camilleri, it isn’t meant to be a desk reference for the struggling project manager. If you are studying project management, or working as a consultant for failing projects, then this is a must-have read. If you are setting up a project management function from scratch in your company, then you’ll find Project Success very useful for starting off on the right foot. But the working project manager looking for a guide to doing day-to-day things right would be better off investing her reading time in something else.
Buy on Amazon.co.uk
Buy on Amazon.com
This review first appeared in Project Tipoffs.
Related posts:
- Book Review: Getting to the Top: Strategies for Career Success The Summer of Books 2010 continues with this review of Getting to the Top. “Evaluating success depends on the scale you select and varies based...
- Book review: Leadership Principles for Project Success “It’s misleading to define project success in static terms, focusing only on the final delivery,” writes Thomas Juli in his book, Leadership Principles for Project...
- Book review: The Success Healthcheck for IT Projects Projects don’t always go to plan. In fact, do they ever? When things are progressing generally in the right direction it’s a good idea to...
Lessons Learned in Project Management: 140 Tips in 140 Words or Less
The preface explains how he was struck by the idea of gathering Twitter-style words of wisdom and making a book out of them.
The book might be Twitter-inspired but the tips are 140 words, not 140 characters. This at least means that the authors are able to make their point in a paragraph or so, and it certainly makes it easier to read. There are actually 145 tips, as there is a section of bonus tips at the end.
The tips don’t appear to be organised in any particular order. The book is not split into themes, or ordered by contributor name. Consequently, it is not a book to read cover to cover, but rather to dip into when you need inspiration. Given the lack of thematic structure, it would be difficult to find relevant tips when you hit project issues – just open the book at a random place and hope that you’ll be inspired out of the difficulties you are in.
Having said that, if you can wade through the tips some of them are excellent. This, for example, from Pawel Brodzinski:
Acting according to schema, although safe, isn’t always the best possible option. Because you normally have access to data about the issues, gather all of the facts while forgetting for a moment the limitations of your methodology. Based on the information, you can then make the best possible decision. Common sense often yields the best possible strategy. Use it whenever standard procedures don’t suit your situation well enough.
The book's back cover with an impressive list of contributors
And this, from Ana Maria Rodriguez:
How much detail should you put into your plan? Do not plan details that you will not be able to monitor, or will not be interested in monitoring during project execution. Do plan details that will require monitoring and controlling later. Keep in mind that you will need to get update information on them later in the project life cycle [sic].
Quite a lot of the tips cover organisational politics, which confirms that the thing project managers learn over time is not how to use new tools for tracking risks or calculating estimates, but how people tick. I found this too when I was researching my own book, Project Management in the Real World. We get better at being project managers because we learn how people operate.
Over half the tips come from Estrella himself and these are a mix of his own experience, in story form, and adaptations of conversations with others or books that he has read. He has a particularly interesting point to share about delegation, which he calls “the ask.”
When delegating tasks to team members, be explicit on what you are “asking” them to do. Do you want them to review the documents and provide feedback, or do you want them to edit and finalise the documents? Instead of simply forwarding the email with an FYI, tell them what to do with it -”no action is needed” or “add a calendar reminder.” A clear “ask” can expedite the completion of tasks.
There are also some good suggestions for no cost team building events. In fact, I enjoyed reading Estrella’s tips more than those from the other contributors.
I was one of those other contributors, and here is my tip from the book:
The average large company, running around 150 projects at any one time, loses £13m a year by not stopping projects that are failing. It’s not always management’s responsibility to cancel projects.if you’re working on something that you know isn’t going to deliver the proposed benefits, you need to speak up. The project manager’s role is partly to direct the work and partly to provide an objective position on how the work is done – and that means stopping everything and starting again, or even not starting again, if necessary. Don’t be afraid to challenge senior people. Not all projects are started from the basis of a competent idea. If you know that a project is going to fail, explain why it should be stopped. It is up to your sponsor to make the final decision to stop it.
How my tip appears in the book
What tips would you add?
Buy on Amazon.co.uk
Buy on Amazon.com
Get it on Kindle
Related posts:
- Book review: Six-Word Lessons For Project Managers What can you learn from just 6 words? According to Lonnie Pacelli, President of Leading on the Edge International quite a lot. He was inspired...
- Book review: 101 Project Management Problems and How to Solve Them AMACOM does do good books, and 101 Project Management Problems and How to Solve Them: Practical Advice for Handling Real-World Project Challenges by Tom Kendrick,...
- Lessons learned: IET debate The Institution of Engineering and Technology held a roundtable debate recently on using lessons learned in project management. I thought it worth sharing, so you...
By the time I was half way through the introduction I liked Todd Williams. I liked his way of thinking, his faith in project management and in people, and his ability to tell stories. I was sold on the idea of a book telling me how to rescue a problem project, even though I wasn’t working on one. Let the lessons begin.
Todd Williams’ book, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure
A five step recovery approach
Williams presents a five step approach to project recovery. The steps are:
- Realisation: you must recognise that there is a problem before you can attempt to solve it.
- Audit: carry out an objective project audit to determine the problems.
- Analysis: analyse the data from the audit to establish root causes and begin to form the solutions.
- Negotiation: mediate between the parties involved to establish an acceptable solution.
- Execution: implement the recovery plan.
So, when you are faced with a project that has fallen off the edge of a cliff, should you stop it completely so that you can put this five step approach into action? Absolutely not. Williams recommends that instead of stopping the project, you should “slow the bleeding”. He writes:
To properly diagnose a system, it must be running. Stopping the project also stops the errant behavior and makes it difficult to find problems and their root causes… Although some situations may benefit from stopping a project following either the audit or the analysis, these are rare. A better approach is to slow the bleeding by implementing remedial fixes.
Whose fault is it?
When a project falters, the easy option is to point to the project manager and blame her. But is it really the fault of the project manager when it all goes wrong? Williams doesn’t think so—at least, he believes that there is more at play than just one person not doing a very good job:
Projects become red because they faltered under the guidance and supervision of the existing steering committee, project sponsor, executive management, and PMO. This group of executives has failed to identify and correct problems before the project fell into serious trouble…The project manager should be accountable for all that has gone on, but the project’s management should have checks and balances to minimise the chances of failure.
In some cases, the problem does not lie so much with people but with policies. Williams writes about a software development project where internal IT policies prevented the product from being tested on computers outside the company’s firewall. As a result, many bugs were missed, the deployment was a disaster and customers were unhappy.
Issues can also arise through poor methods, or poor application of methods. “The organisation’s project management philosophy may be a poor fit for the project,” Williams writes. In short, there are many reasons why projects fail. Analysing the reasons is important, but assigning blame to an individual or group of individuals is rarely the largest part of getting a project back on track.
I enjoyed this book because it felt new. I read a lot of project management books, and many of them—especially those aimed at non-academics—are not half as ‘new’ as this one. You don’t have to be working on a failing project to get some value out of Rescue the Problem Project, because the case studies will help you avoid getting to this position in the first place. But if your project is troubled and constantly reporting a status of Red or Amber, then get your hands on a copy now.
Related posts:
- Book review: The Principles of Project Management “Delivering value is the only real reason to undertake a project.” The Principles of Project Management is part of the Sitepoint stable so, as you...
- Book review: The Lazy Project Manager Pull up a comfy chair, pour yourself a drink and wait for the project team to come to you. Welcome to the world of productive...
- Recovering troubled programmes (part 2) Are you seeing any of the problems faced by troubled programmes that I talked about last week? If so, you need a recovery plan to...
It’s a common cause of project failure directly attributable to us human beings if it is not carried out effectively. It’s considered to be one of the arts of project management – not a science. It features prominently in job specifications and advertisements when organisations are looking for project managers. It basically covers the relationship and communication aspects of projects. There are literally hundreds, if not thousands of references to it across the web and in project management books. Getting to grips with complex stakeholder management and being a politically savvy project manager is in demand, but what does it all mean?
In this article we look at what organisations are actually looking for when they ask for “stakeholder management skills” and then discuss what it is that you should be displaying to prospective employers to demonstrate your competence – in your CV, the interview and also on the job.
With stakeholder management being all about identifying and then understanding the motivations and behaviours of anyone who can affect what you’re trying to achieve on a project; then developing relevant strategies to influence outcomes – it’s no surprise that stakeholder management is one of the top “soft” skills a project manager can have.
For a reference point I started with a quick search of a handful of current job specifications where stakeholder management is referred to and not unexpectedly it shows up in many different shapes and sizes as can be seen in the list below (the number in brackets is where it ranked in the overall importance of the project manager’s roles and responsibilities)…
If you want to learn more about stakeholder management, check out the original article from the July 2011 edition of Project Management Tipoffs, the project management & recruitment newsletter from Arras People. Subscribe to Tipoffs to receive the August edition free – it’ll arrive to your inbox next Thursday!
Be sure to check out the Project Management Tipoffs Podcast for July as well, either at the Arras People Pod Centre, or on iTunes! Subscribe to it here.
Related Posts
- Tipoffs Gets All Political and Stuff!
- One Full Day to Go
- Tipoffs Out Next Thursday
- Tools and Psychological Tidbits for Stakeholder Engagement
- The Stakeholder Rundown
I'm working a proposal for a Program Management Office deployment in a government domain. While I've lead project portfolio management processes, the development of program offices, and the program management office itself, I come across two books that moved my understanding to a new level.
This book has a step by step set of process for standing up a Program Management Office. The idea of a PMO seems foreign to some, even undesirable in the presence of agile software development and the mythical agile project management.
But a PMO has one of several critical purposes in an enterprise organizations. This book and the next speak directly to those - which I'll summarize in a bit.
But first let me make a pitch that I've made in the past around the application of Agile Software Development. Agile as a set of practices has been shown to improve lots of things around "writing software for money." Not the least of which is the institutionalization of the incremental delivery approaches found in our aerospace and defense business.
In A&D Work Packages and the Tasks they contain have limited duration and most importantly measures of physical percent complete in units of measure meaningful to the decision makers. This last part is the Critical Success Factor for any project. The measures of progress using the passage of time and the consumption of resources is simply Bad Management.
As well without a mandated limit on the duration of the Work Packages, the natural tendency is to extend the length of work before there is a measurement of physical progress. Agile does this naturally. So does every Earned Value based program controls system for the simple reason that a formal report is due to the Government every 30 days.
The next book is about the integration of the Program Management Office with Project Portfolio Management. The critical success factor here is to move away from using the PMO and PPM for cost reduction and move toward throughput management.
The notion of cost containment is ill formed and counter to increasing business value. Throughput focuses on meeting organization goals. These goals should be defined in a strategy, which in turn should be defined in a Balanced Score Card style strategy document.
This is the way The Real Way is producing business value. Connect the Balanced Scorecard initiatives, with projects in the portfolio, then manage those projects using measures of physical percent complete.
In each book there is hands on advice for the deployment and application of Program Management Offices and Portfolio Management. This short blog cannot convey these processes or the importance of their application.
But here's a set of questions that must be answered for any organization to be successful in any project domain:
- What are the organization's strategy objectives?
- What projects are active today that support these strategic objectives?
- Can these projects be directly traced to an objective?
- What projects must be completed to achieve each of these strategic objectives?
- Can you measure the performance of each project?
- Is there a mechanism for moving each project forward more rapidly?
Often we consider an opportunity based on how easy it is. The problem with this analysis is that if it's easy, it's often not worth doing. It's easy to start a blog, but of course, starting a blog doesn't really deliver a lot of value. Posting 4,100 blog posts in a row, though, isn't easy. It's do-able, clearly do-able, and might just be worth it.
Successful organizations seek out the do-able. When Amazon went after the big bookstore chains, analysts ridiculed them for doing something insanely difficult. But it was clearly do-able. Persistence and talent and a bit of luck, sure, but do-able.
Sometimes we seek out things that are actually impossible. Building a search engine that's just like Google but better is impossible (if your goal is to dominate the market with it). It's fun to do impossible projects because then you don't have to worry about what happens if you succeed... you have a safety net, because you're dreaming the impossible dream.
Do-able, though, is within our reach. Ignore easy.