I talk to a lot of project managers at networking events and recently gave a presentation about the similarities and differences between PRINCE2, PMP and CAPM. Afterwards, there were a lot of questions. That’s to be expected: training is a big investment both financially and in terms of time, so you want to make sure you have chosen a path that will give you the best return.
The problem is that people want me to make that decision for them.
“But you know about this stuff,” they say. “What would you do?”
It puts me in a difficult situation and people don’t like the answers. Here are some of the impossible career questions that people have asked me in the past, both at events and via email, and the answers that they didn’t want to hear (although I was more polite in real life). Identifying details have been removed.
“I work in software development/engineering/anything and I want to move into management. What course would be best for me?”
Erm… a management course? Or do you mean project management? How much experience do you have in your domain, and what industry do you work in? What does your employer value and where do you want to be in 10 years?
Based on the information you have provided I cannot possibly give you advice.
If you want personalised career coaching I need to know more about you. Or you could do your own research and plan your own career and choose what meets your personal goals.
“I work in IT, what’s the best project management certificate for me?”
What do your colleagues have? What does your employer want you to have? What sort of projects do you work on and why do you want a project management certificate anyway?
I can’t advise you just from one sentence. And frankly it’s better for you to work this stuff out for yourself or with your manager.
“I have 8 years work experience but I do not have the job title project manager. Am I eligible for PMP?”
From what you’ve said how am I supposed to know whether you meet the requirements for applying for the PMP exam? You might be a fisherman for all I know. You might be a very good fisherman but it doesn’t make you eligible.
“Should I do PRINCE2 or PMP?”
Who knows? Without more information I can’t advise you – no one should answer that question for you without finding out more. If you want to use your certificate as a way to get a job, research what employers in your sector in your country value and choose that.
If you want to use your certificate to help you manage projects better then they all will if you are starting from scratch.
If you’ve got a doctorate in project management you probably won’t benefit from doing either.
“Which certification has more value?”
More value to whom? In the UK government sector you aren’t going to get very far without a working knowledge of PRINCE2 because that is what’s valued. Different employers value different things. So do your research about what your employer (or your target employer/sector) wants and go for that one.
“Which certification is more recognised?”
By whom? By me as recruiter: PRINCE2. I work in an environment where all my colleagues have PRINCE2 and if you came in using the language and processes of the PMBOK Guide you would struggle to make yourself understood until you adopt the PRINCE2 approach. That doesn’t mean I wouldn’t employ you.
Every employer, industry and country is different. Do your research about what would make the most sense for your career goals.
“Which is better, CAPM or PMP?”
Neither is better than the other. They are designed for two different levels of experience. Which is better for you? I don’t know anything about you so I can’t say.
“I am a project engineer, am I eligible to take PMP?”
I don’t know what a project engineer is. Even if I did you haven’t told me about your level of education, experience in the job and training. Check the PMP manual and work it out based on your career path to date and what you can evidence.
There are no quick answers
People want quick answers. They want someone to say, “Take PRINCE2, it’s better,” or “PMP is definitely right for you.”
But that would be stupid. It’s stupid for the person giving the answer because unless I was their manager, mentor or coach I wouldn’t have enough information to help them make the best decision for their career. And it’s stupid for the person asking the question because they won’t get a good quality answer. They’ll either get a non-answer like I would give (“Do your research and decide for yourself”) or a quick-fix answer which doesn’t take their personal needs into account and could send them on an expensive and time-consuming path to a certificate that won’t help them grow as a project manager.
There is only one answer to difficult career questions
There is only one sensible answer to these ‘let me just catch you in the corridor and pick your brains for 30 seconds’ career questions. It’s:
Research your market. Understand what is important for your sector, employer and country. Know what your career goals are and where you want to be. Find out what will help you get that. Then go and get it.
It’s a long answer and it’s a hard answer. Because it takes work on the part of the person asking the question.
Well, tough. If you want a good, long, happy career as a project manager (or in any field) then you have to put in the work. And that starts with taking responsibility for your own career progression. By all means come to presentations and networking events and talk to people about their experiences. But ask questions that the presenter has some chance of answering. How about:
- Why did you decide to take the qualifications that you did?
- I think that a CAPM/ITIL/APMP/PRINCE2/etc qualification will help me because [fill in blank]. What do you think about that?
So, am I being too harsh? I can’t help feeling that the people I spoke to went home disappointed and I don’t like leaving people like that. If you have any ideas about how to answer questions like this honestly while not making people feel as if I have dodged the question, I am all ears.
If you do want me to help you unpick the answers to your career questions, or anything else that you are struggling with in project management, I offer coaching via email/Skype and occasionally face-to-face. Let’s talk properly – not just a one sentence question – and with a more rounded picture I can definitely help you make the right choices.
Earlier this month we had a giveaway to win a copy of Laura Brandenburg’s book about starting a career as a business analyst, called How to Start a Business Analyst Career*.
The winner is Stephen from Québec, Canada. Congratulations! Your book should have arrived by now – hope you enjoy it.
* That’s an affiliate link – it doesn’t cost you anything if you click it.
I found another paper presented at in Newspaper systems journal around architecture in manufacturing and ERP.
One of the 12 Principles of agile says The best architectures, requirements, and designs emerge from self-organizing teams. This is a developers point of view of architecture. The architects point of view looks like.
In today’s Expert Views feature I’m interviewing former APM Young Project Manager of the Year, Will Sargeant (pictured below, he’s not the girl in the photo above), who is now works with consulting firm North Highland. We spoke about how the under 30’s are influencing project teams today.
Hello, Will. Why are employers struggling to engage Gen Y team members?
Hello. Organisations have people from across a number of generations in most teams today. Many of the fundamental beliefs, motivations and expectations have changed over recent generations. Many core elements have stayed the same but there has been a fundamental shift and significant change.
People and organisations need to adapt. Organisations can be slow to change and those of older generations are can be less receptive and driving of change. This can jar with the expectations of the younger generations. Some Generation Y members pushing their careers hard are moving into senior management positions and this accelerates the pace of change and the clear differences between people of different ages at similar levels within an organisation.
It seems rather reductive to group everyone together like this. In your experience, or based on your research, how true is this truism of different working styles for different generations?
Obviously there are mass generalisations in any such studies or perspectives of this nature. What blurs the lines further is a lack of consistency around the dates and names for each generation (which also vary over in the US) and how people many sit naturally across or near the borders of each. That said the research shows significant trends.
We have tested this thinking internally at North Highland looking at our London office of over 300 people and our client base over 35 across multiple industries in and around London. The general trends and perspectives seem to largely hold true and resonate strongly.
I have to acknowledge that I’m not in the under 30’s group anymore. What’s the one thing that older project managers like me should do in order to build better working relationships with their Gen Y colleagues?
There is a general theme in the research, studies and points of view I have read that the older generation should wholesale change to adopt the younger generations ways of working (even more disparate as you look at Generation Z). I don’t think it is 100% one way and no change the other. There needs to be a meeting, perhaps not in the middle but the younger generation have to understand the world and expectations of the elder –
“Elder”? Hang on there, I’m not even 40!
– generations in my view. Sorry. I believe quite strongly in ‘first you go along, then you get along’ approach. When you talk to Generation Z members at school or university now, and part of this is maturity obviously, they don’t see the world this way as much.
The expectations are significant and the openness to following someone else’s way doesn’t appear to be the default starting point at all.
Awareness, and then approaching it positively is the way forward. There are many opportunities to use the differences for everyone’s good. Be aware of the differences and then determine how you will address, manage and create opportunities out of these. That’s no different to most elements of the working world really. Our two-page pdf, How Under 30’s Will Make or Break Your Project, highlights some of the specific areas people can think of and practical steps they can take.
It goes both ways. What advice would you give Gen Y’s managing projects in order to engage with their colleagues?
I feel strongly about the need for proactive action in both directions. It is in everyone’s interest to be aware of the expectations of others and manage your team, colleagues and stakeholders in the most effective ways. It is equally vital for Generation Y to understand and manage others and adapt ourselves accordingly.
I find it really powerful to look at my family when thinking about other generations. How my dad (at 58) thinks and sees the world compared to my 21 year old brother. They are entirely opposed. Obviously I am closer to them and their core beliefs than my project team so the differences are more pertinent and that is a powerful learning tool.
I have stakeholders on my current projects that hit that same age range and I need to engage them all. Take that perspective to help get the most out of people in the workplace. This is a key element of everyone being part of a team. Self-awareness, awareness of the expectations of others and bringing that together to create a team with far greater outputs than the sum of the parts.
If you are in a team where everyone is the same age then I would suggest you are missing out immeasurably in many ways. I would be surprised if that was the case in many instances though.
How far is this shift representative of a move away from older tools and techniques as well as behaviour?
Two things here. Firstly, agile methodologies are being used with increasing frequency as we are all aware. This has already bought a new world of tools and methods but is not an excuse to ditch all forms of reporting and planning as ‘admin’.
Second, Generation Y have been brought up on more digestible, snap shot, engaging communications and mediums so how information is shared and presented needs to be updated to ensure it engages this generation.
You also talk about gamification. Does it really work in project teams?
We have found that it does. We did a risk speed dating session across a portfolio and we surfaced over 80 portfolio risks in an hour. There were less than 20 over the 3 months or so before that.
Harnessing competition, prizes and fun are bound to drive engagement. It is in so many places in life and work now. The trick is to set it up right, align the mechanisms to what you really want to achieve and make it simple, timely and meaningful.
I was sorting through a desk draw and came across a collection of papers from book chapters and journals done in the early 2000's when I was the architect of an early newspaper editorial system.
Here's one on Risk Management
Risk management is how adults management projects.
I hear all the time estimating is the same as guessing. This is not true mathematically nor is not true business process wise. This is an approach used by many (guessing), not understanding that making decisions in the presence of uncertainty requires we understand the impact of that decision. When that future is uncertain, we need to know that impact in probabilistic terms. And with this, comes confidence, precision, and accuracy of the estimate.
What’s the difference between estimate and guess? The distinction between the two words is one of the degree of care taken in arriving at a conclusion.
The word Estimate is derived from the Latin word aestimare, meaning to value. The term is has the origin of estimable, which means capable of being estimated or worthy of esteem, and of course esteem, which means regard as in High Regard.
To estimate means to judge the extent, nature, or value of something - connected to the regard - he is held in high regard, with the implication that the result is based on expertise or familiarity. An estimate is the resulting calculation or judgment. A related term is approximation, meaning close or near.
In between a guess and an estimate is an educated guess, a more casual estimate. An idiomatic term for this type of middle-ground conclusion is ballpark figure. The origin of this American English idiom, which alludes to a baseball stadium, is not certain, but one conclusion is that it is related to in the ballpark, meaning close in the sense that one at such a location may not be in a precise location but is in the stadium.
To guess is to believe or suppose, to form an opinion based on little or no evidence, or to be correct by chance or conjecture. A guess is a thought or idea arrived at by one of these methods. Synonyms for guess include conjecture and surmise, which like guess can be employed both as verbs and as nouns.
We could have a hunch or an intuition, or we can engage in guesswork or speculation. Dead reckoning is same thing as guesswork. Dead reckoningwas originally referred to a navigation process based on reliable information. Near synonyms describing thoughts or ideas developed with more rigor include hypothesis and supposition, as well as theory and thesis.
A guess is a casual, perhaps spontaneous conclusion. An estimate is based on intentional thought processes supported by data.
What Does This Mean For Projects?
If we're guessing we're making uninformed conclusions usually in the absence of data, experience, or any evidence of credibility. If we're estimating we are making informed conclusions based on data, past performance, models - including Monte Carlo models, and parametric models.
When we hear decisions can be made without estimates. Or all estimating is guessing, we now mathematically and business process - neither of this is true.
This post is derived from Daily Writing Tips
I write a lot about how to be better at your job, how to improve your skills and so on, and I interview a lot of experts who talk about those kinds of things. Today I want to talk about the opposite: what you should avoid doing at work. I’ve seen project managers and other colleagues crash and burn. It’s not nice to watch, and I hope it doesn’t happen to you. Here are 10 career-limiting mistakes to avoid at work.
1. Not being truthful
A few weeks ago I was contacted by a sales person. This happens often in my job. I told him honestly that I didn’t see any possibility of using his software at work, but that I’m revising Social Media for Project Managers for a second edition and that there would potentially be some scope in learning more about their product for that. He seemed keen and we set up a meeting.
Then I heard that he was contacting my colleagues. Not just one or two but lots of them. Lots of senior managers. Telling them that he had a meeting with me and that as his software would be used by my company in the future that he should meet them to explain about it.
There is a reason that project management has a code of ethics.
This was embarrassing for me. I had no problem with him telling people we were meeting, which was the truth, but the “you’ll be using my application soon” part was a complete lie. And I told him so. I also cancelled our meeting. I can write my book without his case study.
Career-limiting because: People find out if you lie. People find out if you exaggerate the truth. It will always bite you in the bum. So don’t do it.
2. Not doing good handovers
A good handover at the end of a piece of work is important for ongoing relationships and harmony in the office. Plus it’s good practice. Make sure that your project is handed over to the people who will be using the product long term, along with all the associated documents, lessons learned, training material and so on.
Check they know how to contact you in case they need to. However, you should also make it clear that this is not your project anymore and they are responsible, otherwise they’ll lean on you for a long time.
Career-limiting because: No one wants to work with the project manager who emails the operational team a closure document and is never seen again.
3. Not talking about problems
As I talk about in the Better Project Status Reports course, surprises are bad. They are worse than not talking about problems but they are the inevitable consequence. If you don’t talk about problems then you risk hitting your manager with bad news. Project sponsors don’t like bad news either.
Don’t run a watermelon project (that’s one that is green on the outside but red when you cut it open to examine it more closely). Talk honestly about what is going wrong. Report your project as Red or Amber when your project isn’t Green. Let people know what you are doing about it.
Don’t run a watermelon project: that’s one that is green on the outside but red when you cut it open to examine it more closely.
Career-limiting because:People will feel as if you don’t have a handle on what’s going on, or that you are not truthful. Or both.
4. Not taking decisions
Good initiatives die through stagnation. Often we need decisions to be made and no one else will step up and do it. When no one around you will make the decision and you think it is safe to do so, make the decision yourself.
Be empowered until someone tells you that you are not. You probably have more authority than you think, and you can certainly take more authority than you have. You’re managing a piece of work, so step up and do it otherwise you are not showing demonstrable leadership. You are not being accountable. The buck stops with you. End of.
[Find out why there is no such thing as a bad decision.]
Career-limiting because:Managers want to work with project teams who get work done. Decisions make that happen, and show that you are acting in a leadership role.
5. Not treating your colleagues as customers
Colleagues are not an annoyance. They want a report in a different format? They want a meeting on a Friday afternoon when you’d rather be packing up to start the weekend early? It’s inconvenient, but they are your customer. Treat them accordingly.
By all means negotiate the time of that meeting and try to get the best outcome for yourself as well.
Career-limiting because:Other people pay your wages. Make the link.
6. Not saying no
You can treat someone like a customer and still manage to say no to them from time to time. Don’t feel that you have to meet every stupid whim (project stakeholders and your colleagues are not above doing idiotic things sometimes).
You’ll be faced with scope changes that they don’t want to pay for, unreasonable requests for extra work or impossibly-speedy work and more. Say no. Be polite but don’t be a doormat.
Career-limiting because:You’ll be seen as a walkover and someone who is not truly in control of the work. And because if you are in a consultancy or service business and customers keep asking for work that you agree to without being paid for it, you’ll go out of business.
7. Not doing lessons learned
Most post-implementation reviews end up with a list of lessons captured. Lessons captured are not the same as lessons learned. I concede that they are better than nothing.
Lessons captured are better than nothing. Lessons learned are better than lessons captured.
Not doing the exercise to find out what lessons the team learned when a piece of work is done means you are unable to learn from your mistakes. You will not revise and standardise your processes. You’ll never get any better at your job, and your company will never improve its organisational knowledge.
Career-limiting because:You’ll never improve your performance, and you’ll never be able to demonstrate that you can improve your performance.
8. Not working with a sponsor
This one isn’t your fault. Let’s say you start working on a project and then the sponsor leaves. They are not replaced. Or the project falls way down the list of priorities and although you have a sponsor named in your Project Charter they don’t actually contribute anything.
However, not working with a sponsor is definitely career-limiting.
Career-limiting because:You’ll have no one to champion your successes and support you. You’ll have no one who can put you forward for new opportunities based on your performance at work.
9. Not staying up to date with training
What I do now as a project manager isn’t the same as what I did ten years ago. It just isn’t – my personal skills have developed as has my technical ability to do my job. Partly that’s down to the fact I’m older and have more experience, but partly it’s to do with taking an active interest in getting better. I’ve taken training courses, read books and generally looked out for my own progression.
You should too.
Here are some of my favourite training options right now*:
- If you’re hoping to do the PMP exam then try Brain Sensei. It’s a video training course based on the concept that work is like dealing with feuding factions in ancient Japan, and very well put together.
- Struggling to understand Earned Value? This short online course from Andy Kaufman will help.
- It’s impossible not to like the training material put out by Cornelius Fichtner; I’ve listened to his online learning materials for years. The PDU Podcast is aimed at people who are collecting professional development units for their PMI credentials but it’s also full of useful material for project managers and their teams looking to keep their skills up-to-date. Get a monthly subscription here (if you don’t like it you can cancel it at any time).
Career-limiting because: You’ll be unable to prove you are continually learning, which is often a criteria for showing your managers that you are serious about your career. You’ll limit your chances of hitting any continuous professional development requirements for your professional body.
10. Not listening to your experts
Every team has experts. They contribute to your plans. They do most of the work. As a manager, your role is to make it easy for them to do their jobs.
The problems come when you used to do their job, and you still want to. Managers meddle. They override decisions made by the people actually doing the work. They make up their own estimates based on how long they think things will take. Mostly they get it wrong because life has moved on since they were in the job. They aren’t always up-to-date with the latest processes and practices. Don’t make the mistake of thinking you know better than they do.
Career-limiting because: They know better than you. Honestly. Ignore them and you’ll make mistakes that could cost you the success of your project. And you know that you’re mainly judged by the success of your last project, don’t you?
*This article contains affiliate links at no cost to you.
I never met Carl Sagan. I've read his materials (both technical and popular) and listened to his talks. Dr. Sagan was a fierce questioner of many things. But in that questioning process is a framework by which answers can be discovered. Here's two nice quotes
The conjecture there is cause and effect without confirming cause and effect is another common naive thought process. We get that from the anti- vaccine , global warming deniers to name a few. We also get this from those who conjecture that estimates are the smell of dysfunction without every stating the dysfunctions, discovering the cause and effect connections for the dysfunction (the unstated dysfunction).
Dr. Sagan primary message was and still is an
I don't what to believe, I want to Know
If we seek to improve the probability of success for our software intensive systems, we can't just believe the unsubstantiated conjecture of a group on unhappy developers tired of be abused by bad managers. We need tangible evidence that their conjectures are not only testable outside their personal anecdotes, but also those conjectures are not violations of the basis of all business decision making.
And just for the record.
- Estimating is hard, so are many things. That does not remove the need to estimate when making decisions in the presence of uncertainty.
- Estimates are misused by bad managers and even well intentioned managers. That does not remove their need when making non-trivial business and technical decisions. By non-trivial I mean value at risk is at a level that unfavorably impacts the business when the decision turns out to be wrong.
- All project work is probabilistic with uncertainty of the future outcomes. Making decisions requires making estimates
- Assessing value requires we know the cost to achieve that value. Since but value and cost are probabilistic, no assessment of value can take place without estimating both cost and value. This is the basis of Microeconomics of business management.
A final thought about unsubstantiated opinions, masking as personal anecdotes (thanks for this Peter)
The biggest challenge facing project management today is that project-related work and jobs are growing too quickly for our approaches to professionalism to keep up.
Let me explain what I mean. There are a lot of acronyms coming, so apologies in advance for that.
The world of work is becoming more focused on projects. I don’t think it’s just project professionals who would say that – business leaders are also aware of the fact that projects are a core part of any company, and project management standards and approaches are being applied to more things.
The role of the Project, Programme and Portfolio Office is growing. There are different types of roles available now to people who want to work in projects. You could be a PMO specialist, a risk professional or a project support officer. The management frameworks and organisation structures that support project-based work are in use in many companies.
However, this growth means that project management has different interpretations for different people. Project management jobs are offered with salaries of £20k to upwards of £80k. That can’t possibly be the same job with the same responsibilities.
The role of industry bodies
The approach we have taken to professionalism and explaining what project management is really revolves around industry bodies. In the United States this is relatively clear, as PMI sets the standards for what project management means. I don’t say this because I’m a particular fan of the PMBOK® Guide or the PMP credential, but because in the US there isn’t as much competition between industry bodies (correct me if I’m wrong – let me know in the comments below).
In the UK it is a different story. We have AXELOS, which produces and manages the PRINCE2 and MSP frameworks. These are the de facto requirements for project and programme managers over here. We also have the Association for Project Management which is affiliated to the IPMA. They have their own body of knowledge and credential scheme (which is also very good). Then we have a small but relatively active PMI Chapter, so there are people with PMP and other PMI credentials.
The qualification challenge
For employers, it’s a mess. Do you want a PRINCE2 Practitioner or a PMP, or someone who has both? What does APMP mean and it is better or equivalent to a Master’s degree in Project Management? If I want to recruit a PMO Manager, what should I be looking for? There is no national standard to help employers make the right decisions for their companies.
For individuals, it’s worse. I’m often contacted by people wanting to know which course they should do. Most employers advertise for people who are PRINCE2 certified, but that course won’t teach you to do proper scheduling and it certainly doesn’t reflect your experience in the field. So should you get PMP as well?
What about the new Registered Project Professional designation from APM? This is still relatively new in industry terms but the idea is that people who have RPP then adopt Chartered status and become Chartered Project Professionals when the APM is awarded its Royal Charter. That will apparently move those people into the same stratosphere as Chartered Accountants or Chartered Surveyors.
So let’s say you want to go for that. Who will pay for it? Many employers will only pay membership fees to one professional body for you (or none at all). Do individuals have to pay for PMI membership and APM membership and ask their employers to send them on PRINCE2 courses every 5 years for recertification?
It’s very complicated.
Why I don’t have the answers (and neither does anyone else)
Articles like this are supposed to end with the author putting forward their suggestions for how we should tackle the challenge. The problem is that I don’t have the answers. Professional bodies won’t suddenly stop producing certificate-based courses. It is how they make money and how they convince employers that they are relevant to today’s working environment, and in my experience the courses and credentials are very good.
I don’t have an issue with the standard of project management education – I just worry that there is too much of it, which makes it hard for employers and individuals to know what the best option is for them.
I can’t see that any of the professional bodies in the UK would give up marketing their services because someone else is doing a similar thing, and why would they? What I would like to see is more alignment and collaboration between them, so that it is easier to compare bodies of knowledge, standards, frameworks, certificates and credentials and whatever else is out there. More talk about how different post-nominals fill different requirements.
We need project management as a profession to hang together, not become more fragmented. The project-based workplace is here to stay, and the discipline of project management needs to catch up pretty fast so that companies see the value and know where to turn for professional advice.
This article is based on a podcast I did with Peter Taylor. You can listen to Peter’s podcasts here. My comments were part of his Best of British series.
There is a popular notion in the Agile world that with continuous deployment and frequent shipping, dates should cease to matter. The next big feature should be ‘just’ one release of many.
But the Capabilities provided by the software system many times have dependencies on other capabilities. Here's an example of a health insurance provider network system. There is a minimum number of features needed to provide a single Capability that the business can put to work making money. Certainty continuous delivery of features is always a good idea. But the business is looking for capabilities not just features. The Capability to do something of value. This is the Value used - and many times misused - in Agile.
It's not about working software (which is necessary). It's about that working software being able to produce measurable value for the business. That can be revenue, services, operational processes. In the enterprise these Capabilities need to be delivered in the right order at the right time for the right cost for the business to meet it's business goals. Rarely are they Independent in practice.
To discover what capabilities are needed, here's one approach taken from our Capabilities Based Planning paradigm
Here's a more detailed process description.
This of course goes for the #Noestimates notion as well - ask those paying if they have no interest in knowing when those capabilities will be available and how much they will cost. You may get a different answer that the one provided by the developer, who does not own the money, the business accountability, or the balance sheet performance goals.
Many voices in the IT Project Failure domain reference the Standish Reports as the starting point.
These reports have serious flaws in their approach - not the least of which is the respondents are self-selected. Meaning the population of IT projects is not represented in the returned sample. Another popular misrepresentation is the software crisis. Using a 30 year old NATO Report, it is conjectured the crisis can only be fixed by applying a method, without determining the Root Cause - if there ever was one.
These approaches can be found in How to Lie With Statistics. That aside there is another serious flaw in this project failure discussion.
There are solutions looking for a problem to solve. Tools, processes, practices, vendors, consultants. But nearly always the needed Root Cause Analysis is not the starting point. Instead the symptom is used as the target for the solution. But first let's establish the framing assumptions for project success.
Successful execution of Enterprise IT, Aerospace, Defense, and Government Software Intensive Systems (SIS) requires management discipline to identify what “Done” looks like, provide measures of progress toward “Done,” identify and remove risks and impediments to reaching “Done,” and assure timely corrective actions to maintain the planned progress towards “Done.”
I work in a domain where Performance Assessment and Root Cause Analyses is a standard function of program management. Increasing the Probability of Program Success is a business strategy. There are many approaches to increasing the probability of program success. But first what are some Root Causes of failure? Here's the top 4 from research:
- Unrealistic Performance Expectations, missing Measures of Effectiveness (MOE) and Measures of Performance (MOP).
- Unrealistic Cost and Schedule estimates based on inadequate risk adjusted growth models.
- Inadequate assessment of risk and unmitigated exposure to these risks without proper handling plans.
- Unanticipated technical issues without alternative plans and solutions to maintain programmatic and technical effectiveness.
There are dozens more from the Root Cause Analysis efforts in software intensive systems, but these four occur most often. Before suggesting any corrective action to any observed problem (undesirable effect), we need to know the Root Cause. Asking 5 Whys is a start, but without some framework for that process, it too becomes a cause for failure. A method we use is Reality Charting. It forces the conversation to cause and effect and prevents the story telling approach where Dilbert Cartoons are descriptions of the cause - the SMELL - of the problem.
One common offender to this tell me a story and I'll tell you a solution is the No Estimates paradigm. Estimates are conjectured to be the smell of dysfunction. No dysfunctions are named, but suggesting we can make decisions with No Estimates is the solution. Besides violating the principles of Microeconomics, not knowing the outcomes of our work in the presence of uncertainty means we have an open loop control system. With Open Loop we don't know where we're going, we don't know if we're getting there, and we don't know when we're done. This in turn lays the groundwork for the Top Four Root Causes of project failure listed above.
- The performance expectations are just that - unsubstantiated expectations. What is the system capable of doing? Since the system under development is not developed yet, we have to make an estimate. This is an engineering problem. What's the model of the systems functions? How do those elements interact. There are simple ways to do this. There are tools used for more complex systems. Mathematics for Dynamic Modeling is a good start for those complex projects.
- Unrealistic Cost and Schedule estimates are very common. Any business that's going to stay in business needs to know something about the cost to develop it's products and when that cost will turn into revenue. This is the very core of business decision making. Poor estimating is a Root Cause of many project failures. Estimating Software Intensive Systems, Projects, Products, and Processes is a good place to start.
- Inadequate risk assessment many times means ZERO risk assessment. What could possibly go wrong, let's just get started. Agile is billed as a risk management process. It is not. It provides information to the risk management process, but it alone is not risk management. Continuous Risk Management Guidebook is a starting place for managing risks. As Tim Lister says Risk Management is How Adults Manage Projects.
- Unanticipated technical issues are part of all projects. Managing in the presence of uncertainty deals with both programmatic and technical uncertainty. Both are present in the Top 4 Root Causes. As a result of risk management, these technical issues may or may not be revealed. The uncertainties found on projects are reducible and irreducible. For reducible uncertainty we need to spend money to buy down the resulting risk. For irreducible uncertainty we need margin. Both these require we make estimates because they are both about outcomes in the future. Here's a start to managing in the presence of uncertainty.
So here's the punch line. Dealing directly with the Top 4 Root Causes of project failure starts with making estimates. Estimates of the probability of meeting the expected performance goals, when they are needed for project success.
Estimates of cost and schedule to assure we have enough money, or the cost is not more than the revenue, and that doing to work for the needed cost will show up on the needed time so our revenue stream will pay back that cost. Showing up late and over budget, even with a working product is not project success.
Estimates of risk are the very basis of risk management - managing like an adult. What could go wrong requires we estimate the probability of the risk occurring or the probability distribution function of the natural variances, the probability of impact, the probability of the effectiveness of our mitigation, and the probability of any residual risk.
Unanticipated technical issues are harder. But if we know anything about the technical domain, we can come up with some problems that can be solved before they become problems. This is called Design. If we now nothing about the technical domain, nothing about how to deliver a solution for the customer, nothing about the cost to provide that solution - we're the wrong people on the project.
Two train journeys and The Rosie Project* was finished. I only realised when I looked it up on Amazon that’s it is part of a series. I have a feeling I’m going to have to get the others. I read a lot of non-fiction and I’m constantly surprised at how consuming a novel can be. This one was really, really good, and I’m not even a big fan of girl meets boy plotlines. It was lent to me by a friend and it has a list of names in the front so we can tick off who has read it and who is next. Now I have to remember to pass it on because it would be unfair not to keep sharing this unconventional love story.
In more work-related reading I’ve read most of Persuasive Copywriting: Using Psychology to Engage, Influence and Sell by Andy Maslen. I started off thinking there would be some revelations in there about how I could make my writing better and it turns out that I’m not that bad. At least, I understand the theory – whether I execute it or not is a call you are better placed to make than me.
Aimed at professional copywriters, it’s a detailed but easy to read book that would benefit people who are looking to write better at work as well. There are exercises (none of which I have done) so more dedicated people than me can practice and hone their skills.
Still on the pile to read is Mark Woeppel’s Visual Project Management. I thought about taking it on holiday (we just got back) but it’s awkward trying to take notes when you’re juggling all the stuff I need to carry around to get the family out the door. So I’ve left it for commuting or home-based reading.
I also haven’t read the new APM Competence Framework, but this is up there with my must-reads. What I’m particularly looking forward to (because I’m like that) is how they have managed to ditch 20 competences to get the list down to 27. That’s a major piece of streamlining and a huge achievement. I assume it doesn’t mean that project managers have to be less skilled than they were under the old framework.
Last month AXELOS launched PRINCE2 Agile and I wanted to read more about that, but you had to create an account to get the free preview and Murray was playing at Wimbledon and it was hot and I couldn’t be bothered. So I can’t tell you anything about that – sorry. I think it’s a good idea as it aligns the vocabulary between Agile and non-Agile projects, according to the person I sat next to at the #EVA20 conference dinner. The more I learn about Agile, the more I think all projects have similar approaches to getting things done. Anything that helps others see how we are similar instead of stressing the differences has to be a good thing.
Let me know your thoughts on my choices for this month – got any recommendations for August?
* This article contains affiliate links at no cost to you.
When there is a discussion around making improvements to anything, trouble starts when we don't have a shared understanding of the outcomes. For example, speculating that something can be done or that something should be stopped in pursuit of improvement has difficulty maintaining traction in the absence of a framework for that discussion.
The discussion falls into he said, she said style or I'll tell you a story (anecdote) of how this worked for me and it'll work for you.
Over the years I've been trained to work on proposals, provide training materials, write guidance documents, and other outlets - PodCasts, conference presentations - all designed to convey a new and sometimes controversial topic. Connecting agile and earned value management is the latest.
There are several guides that have formed the basis of my work. The critical success factor for this work is to move away from personal anecdotes - although those are many time used inside a broader context to make the message more personal. Rather start with a framework for the message.
A good place to start is Cliff Atkinson's Beyond Bullet Points.It's not so much the making of Power Point briefings, but the process of sorting through what are you trying to say. Version 1 of the book is my favorite, because it was simple and actually changed how we thought about communication. Here's a framework from Cliff's 1st edition.
So when we hear about we're exploring or all we want is a conversation and at the same time the suggestion - conjecture actually - that what we're talking about is a desire to change an existing paradigm, make some dysfunction go away, take some correcrtive action - ask some importanrt questions:
- Is this a framework for discussing these topics? Are we trying ti understand the problem before applying a solution?
- When applying the solution based on the understanding, is there any way to assess the effectiveness of the solution? Is this solution applicable beyond our personal anecdotal experience?
- Cam we analyze the outcomes of the solution applied to the problem and determine if the solution results in correcting the problem?
- Do we have some means of evaluating this effectiveness? What are the units of measure by which we can confirm this effectiveness. Anecdotes aren't evidence.
- And finally can this solution be syndicated outside the personal experience? That is are our problem areas subject to the same solution?
Do you think business is becoming more social? That’s the basic premise in two books I have read for research recently.
The Social Age
In A World Gone Social: How Companies Must Adapt to Survive*, Ted Coine and Mark Babbit say that business is becoming more human because we are social creatures. They also say that the challenge facing managers is to adapt or flounder:
“Times have changed. Today…we’re deep in the midst of a cataclysmic (and wonderful) change in the way business is done. What used to be considered impossible is now happening. Fuelled by collaboration – and built on the foundation of organic communication with a click of a button or a share sent via the touch of a screen – the Social Age is upon us… [F]lat companies with open communication, authentic leadership, and engaging cultures are crushing it – and they’re coming to a market, and an industry near you.”
Afraid? I hope you work in an organisation that’s embracing this change. But also I don’t think it’s happening as shockingly quickly as all that. Big business and government are slow to change, although today we talk about ‘slow’ as meaning ‘a year or two’ not ‘ten years’.
The business benefit of digital
There’s a business imperative to all this change. Leading Digital, by George Westerman, Didier Bonnet and Andrew McAfee, summarises research by the authors that puts categorises companies based on their level of and commitment to technological change. They call the companies who are best at doing this ‘Digital Masters’. Digital Masters, they say, outperform their competitors:
“Masters are 26% more profitable than their average industry competitors. They generate 9% more revenue with their existing physical capacity and drive more efficiency in their existing products and processes.”
Not bad. Unsurprisingly, the industries they tag as Digital Masters include high tech, retail and banking. Pharma lags behind, not because of lack of digital ‘features’ but because teams work in silos and lack digital leadership.
The missing vision
Leading Digital goes on to say that only 42% of 391 companies surveyed had a digital vision, and only 34% of those had shared it with senior and middle managers.
Whether you’re implementing online collaboration tools for project teams or coming up with a full-scale social strategy for an international business, a lack of vision is going to hold you back. Interestingly, it’s more important than the choice of tool itself. The authors write:
“The tool is not important. What matters [is] the open dialogue and the engaging of the organisation to deliver the digital vision.”
What this means for project managers
Project managers need to get comfortable working with social and working with digital. Is it the same thing? No, I don’t think so. Social tools connect individuals and prompt collaboration – much of what you do with project teams. ‘Digital’ is a wider term that (in my view) includes big data, analytics, consumer apps and a broader approach to enterprise transformation than ‘just’ introducing collaboration tools for teamwork.
Whether you agree or not, the point both books make is that the workplace is shifting to embrace new technology and that means new ways of working, whether we like it or not.
To give an example of how companies are adapting working practices to fit this new business model, Coine and Babbit talk about social recruiting. Social recruiting is basically finding candidates online. They write:
“We need good people who will succeed in their roles here; good people are increasingly online; therefore we need to recruit online.”
This is just a small, tangible example of how the world of project management is changing: you might find your next job comes through a Facebook message rather than a headhunter because we’re living and working in a world gone social.
* This article contains affiliate links at no cost to you.
There is a nice post from Trent Hone on No Estimates. This triggered some more ideas about why we estimates, what the root cause of the problem #NoEstimates is trying to solve and a summary of the problem
A Few Comments
All project work is probabilistic, driven by the underlying statistical uncertainties. These uncertainties are of two types - reducible and irreducible. Reducible uncertainty is driven by the lack of information. This information can be increased with direct work. We can "buy down" the uncertainty, with testing, alternative designs, redundancy. Reducible uncertainty is "event based." Your power outage for example. DDay being pushed one day by weather.
Irreducible uncertainty is just "part of the environment." It's the natural varaibility embedded in all project work. The "vibrations" of all the variables. This is handled by Margin. Schedule margin, cost margin, technical margin.
Here's an approach to "managing in the presence of uncertainty"
For my experience in Software Intensive Systems in a variety of domains (ERP, Realtime embedded systems, defense, space, nuclear power, pulp and paper, New Drug Development, heavy manufacturing, and more) #NE is a reaction to Bad Management. This inverts the Cause and Effect model of Root Cause Analysis. The conjecture that "estimates are the smell of dysfunction" without stating the dysfunction, the corrective action for that dysfunction, applying that corrective action, then reassessing the conjecture is a hollow statement. So the entire notion of #NE is a house built on sand.
Lastly the Microeconomics of decision making in SWDev in the presence of uncertainty means estimating is needed to "decide" between alternatives - opportunity costs. This paradigm is the basis of any non-trivial business governance process
No Estimates is a solution looking for a problem to solve.
Good grief, these videos were hard to track down.
PMI produced a series of video interviews with Beth Partleton on women in project management. The series is 10 short videos; here are the five best. They are all just a few minutes each and safe for work.
This one is advice for men managing women:
And finally, this one asks the question: when will we stop talking about ‘women in project management’?
I finally found these videos thanks to a link on Dave Gordon’s blog. Thanks, Dave!
On any project with significant Value at Risk Economic Analysis provides visibility to the data needed for decision making. This Value at Risk paradigm is a critical starting point for applying all processes of decision making. The choice of decision process must be matched to the opportunity cost (actually the value of the loss for the alternative not chosen).
- Objective - what capabilities need to be produced by this project which the customer will value (in some useful units of measure)? These objectives can be easily described by Capabilities of the Outcomes. Features, stories, requirements are of little use to the customer if they do not directly enable a capabilities to accomplish the business mission or vision. The customer bought the capability, not the feature.
- Assumptions and Constraints - there are always assumptions. These are conditions in place that impact the project.
- Alternatives - there is always more than one way to do something. What are costs for each alternatives?
- Benefits - what are the measurable benefits for this work? It can be monetary. It can be some intangible benefit.
- Costs - what will it cost to produce the value to be delivered to the customer? Along with this cost, what resources are needed? What schedule are these resources available?
- Rank Alternatives - with this information we can rank the alternatives in some objective manner. These measures can be assessment of effectiveness or
- Sensitivity and Risk Analysis - tradeoffs are always probabilistic in nature, since all project work is probabilistic in nature. Rarely if ever are the single value non-varying numbers. This is the case only when the work is complete and no more activities are being performed. These actual values are useful, but they can be used for making future decisions only if there past performance statistical behaviors are collected. This is the Flaw of Averages problem. No average has value without know the variance.
- Make a decision - with all this information we can now make decisions. Of course the information about the past can be used and of course there is information about the future. Both are probabilistic nature.
With these probabilistic outcomes driven by the underlying statistical process of all project work, we need to be able to estimate all the values of the random variables and their impact on the processes above.
Next is an example of applying this probabilistic decision making in the presence of uncertainty for cost and schedule assessment. This can be for other probabilistic variables on the project. Technical Performance Measures, Measures of Effectiveness, Measures of Performance, Key Performance Parameters, and many other ...ilities (maintainability, supportability, survivability, etc.)
When was the last time you hit a significant milestone at work and did something to celebrate? Or simply celebrated the fact that you’d made it through another day on a difficult project? I don’t think we do that enough, so here are 15 ways that you can celebrate success with your team.
1. Meal out
This works well on teams with fewer than 20 people in my experience. A meal out with 150 work colleagues (although I have attended a couple of those) turns into a big event where you only sit with and talk to your friends. The host doesn’t get round to chat to everyone and it kind of defeats the object of a personalised thank you. Also, it’s fiendishly expensive to take people out for dinner these days. However, for small teams it can work well.
2. Drinks out
Drinks out cost less than a meal and work better when there are large groups of people involved. On one project we hired a private area in a pub and they catered with bar snacks too. We actually got a lot more food than we expected, which was great. We chose a pub near the office so people could get their easily – it was a five minute walk. I thought that was important as often people are in a rush to get home from work and I know I wouldn’t be prepared to take too much time out of my home life to hang out with people I already spend the best part of my day with.
On one project we had too many people involved to take them out for drinks so we bulk bought bottles of wine (and some soft drinks too) from the local cash and carry. Then we made personalised gift vouchers. You can read more about this attempt at thanking people on a budget here and find out why it didn’t work out so well.
3. Say ‘Thank you!’
It costs nothing to say thank you, and it’s my belief that you should do so as often as possible. You can never appreciate people too much. And you don’t have to wait for a significant milestone to do so. Just say it whenever.
You can also email a thank you message. Some people will appreciate this more as they can file it away for their end of year review more easily than if you had just said it.
4. Time off
If it’s within your power, offering time off works well. If your team have had to put in a lot of unrecognised overtime to get to the point where you are now celebrating success, then try to recognise that by giving it back to them as time off in lieu.
5. A letter from your sponsor
Many people like to know that those higher up have recognised their efforts and appreciate them. I once got our CEO to write letters of thanks to a large team who were instrumental in getting one project to the next significant milestone.
It meant a lot to people to know that he was aware of what the team had achieved.
6. Gift vouchers
Gift vouchers can work well and can equally fall flat. I once got some vouchers for a shop that was miles away and inconvenient to get to. Not a great gift.
However, many vouchers today can be used online as well as in real stores. Gift vouchers can be a bit of a cop out but they are good on large teams and let people choose a thank you present for themselves.
7. Company scheme
If your company runs a staff recognition scheme then use it! Many companies have schemes that offer small gifts to individuals and teams based on their contribution to business success. If it comes with a certificate then that’s even better.
8. Supplier gifts
Back in the days before the recession hit, suppliers often had a lot of free samples to give away. You might be working on a project with a vendor who still has got a budget for giveaways. I once bought gift bags (and didn’t charge them to the project budget, in case you were wondering) and then commandeered the best freebies I could from a range of vendors. We got umbrellas, USB keys, nice pens and I can’t remember what else. Then I filled a bag each for the team.
I have no idea if they appreciated a bag of what was effectively free stuff but I still use my free umbrella.
If a supplier helped you get to this point, there’s no harm in asking them if they will contribute to something to help celebrate the success achieved.
9. Gift from you
If you can’t get the money from your company or a supplier for a gift, and (importantly) you can afford it, think about giving your dedicated team members something from yourself. I have bought my team gifts before: again, bottles of wine. I chose wine from the year that they started on the project – it was a project that ran for several years and we had worked together closely over that time.
Ask my team what they don’t want to do and they’ll say bowling. But it works for many teams, and I don’t mind it myself. It’s a fun, not too expensive way of marking the end of a project or a successful completion. Plus it has the added benefit of competition.
I think this has only ever worked for me once, on a team away day and we were doing it as a team building exercise rather than an end-of-project celebration. Still, it is something to consider, and quite cheap if everyone brings a dish.
We played party games too.
12. Coffee card
I wish people celebrated my successes by giving me a gift card for Pret! I’d even take Starbucks. If picking up a coffee on the way to work is part of the fabric of your team then this would be a welcome small treat. You don’t need to load it with much money for it to be worth a couple of coffees.
13. Comedy club (or theatre)
A bigger, but less food-orientated outing is to take your team to a comedy club. When we did this (it was a team Christmas outing rather than a celebration) it was a great night. Some of the acts fell flat, but others were fantastic. We created a shared experience too so it doubled as a team-building event.
If comedy isn’t for you, think about a trip to the theatre or even a ghost walk (or other guided walk) around your local area.
14. A book
Why not thank you team for a job well done by buying them a book? How about this excellent book* to help them manage their work better? Oh yes, I wrote that!
15. Ask them
If you don’t instinctively know what your team would like from this list – or you can’t tell if they would like any of them, then you don’t know your team very well. That’s OK, it happens. Especially on big teams.
The best way to find out how people would like to be thanked is to ask them. Yes, it takes away some of the spontaneity but in my experience people would much rather get something they want than something they don’t value. Most individuals will appreciate the fact that you care enough to thank them in a way that is meaningful to them.
Which of these have you tried? Let us know in the comments, and share your suggestions for alternative ways to thank the people in your team for a job well done.
* This article contains affiliate links at no cost to you.
Today’s free project management template is a change log. You can use this to record all your changes, who is responsible for doing the work or analysing the change and the outcome.
Changes need to be recorded carefully because on long projects you won’t be able to remember why you agreed to a certain change – trust me, I’ve forgotten why we said we would do something often enough.
A change log (or change register) lets you note down all the details related to that change. The owner is particularly important as someone needs to be responsible for the analysis and taking the change through the process until it is ultimately approved (or rejected). At that point the owner can change and the actual work be allocated to someone else.
IE9 users: I’m sorry my site looks so awful on your browser. You won’t be able to see the download button. Try from your mobile, tablet, Firefox or Chrome, or get in touch with the contact form and I’ll send it to you.
Click the button below to get the change log template – you’ll need to enter your email address.
I hope you find it useful!
Project success starts with a simple principle. We have to Know What Done looks like before we start.
In Michelangelo's painting to the left, the two fingers are not touching. In the paradigm of a deity this may be sufficient to complete the job. In our our mortal world this is a nice example of almost done.
It's more than common that we are stuck at 90% complete for a long time after the planned completion date. There are several independent variables here that are the sources of this problem.
- The estimated and then planned completion date and the associated budget are incorrect - because they are not credible. So arriving late and over budget is the outcome, since the confident in the actual data and budget was low on day one. We're steering to the wring target.
- The execution of the credible Performance Measurement Baseline is flawed. We can't stay on schedule, budget, or technical performance targets. Why lots of the reasons, but the plan is good but we can't execute.
- The plans and execution churn too much. The target is moving.
So What's a Project Manager to Do?
Here are six steps to creating a credible picture of what done looks like and execution to that understanding.
- Define the work in terms of products or services that must be delivered to implement the needed capabilities from the project.
- Build a strategy showing how each of the deliverables will be produced and how these deliverables will increase in their maturity as time passes.
- Identify the reducible risks for each of the deliverables and the work needed to reduce this risk and the measures of this risk reduction to assure they are handled.
- Build plan of the order of the work that provides the increasing maturity according to the strategy.
- Identify the irreducible risks and margins needed to protect the project from the unfavorable variances that arise. This means schedule margin, cost margin, and technical margin.
- Baseline this information and apply change controls so variances can be used to produce corrective actions.
These six steps can be applied to any project management or product development approach from agile to formal DOD acquisition.
The key here is to connect the Programmatic performance (cost and schedule) with the Technical performance of the project, measure the variances of actuals to plan and take corrective actions to get back on plan or better yet stay on plan.
The #NoEstimates advocates have asked us to see estimates as a smell: an indication of possible decision making dysfunction. It might be useful to explore what's causing the smell.
In the normal business process world, when we encounter a dysfunction, Root Cause Analysis is an approach to discover the cause and effects of the dysfunction.
Since the Primary Effect is described as dysfunction but not stating what this dysfunction is, let's apply RCA in the form of the Apollo Method to the statement of the #NoEstimates advocates.
But first some background on RCA and the Apollo Method.
- Inability to estimate when the project will complete, how much it will cost when complete, and what capabilities will be delivered at completion and along the way that meet the business plan.
- Misuse of estimates.
- Abuse of estimates.
- Cost of estimates not appropriate for the Value at Risk.
It's been suggested that asking 5 Whys is a place to start. It is well understood that simply asking may be necessary but far from sufficient to discover the Root Cause of any dysfunction. Source of the problem with the 5 Whys approach starts with our natural story telling approach to problem solving.
Finding the source of any dysfunction is straightforward:
- For each Primary Effect - in this case Management Dysfunction - ask why
- Just asking why is necessary but not sufficient
- The answer needs to have a connect to the Primary Effect - the dysfunction
- Estimates are hard - without a traceable connection to the dysfunction, suggesting stopping estimates will remove the dysfunction is nonsense. Stopping them has no good reason, other that estimates are hard.
- This is like asking your young child to eat their peas. I don't like them, Why, Because they taste bad, Why, because I don't like them.
- Look for Causes in actions and conditions
- Find a condition from the Event. What has to be in place for the Event to take place?
- Find an action for the Event. What was actually DONE to cause the primary event?
- The only value of knowing if a cause is an action or a condition is that it tells us which
- Connect all the causes with a caused by association
- Connect all these in some form to see the causal linkage between the Action and Conditions and the Primary Event.
- Support each cause with evidence
- Here's the hard part and where the #NoEstimates advocate fall flat on their face.
- Show evidence that the existence of estimating and resulting estimates (good or bad) are the CAUSE of the dysfunction.
- Then and here's the really hard part in the RCA paradigm - show that the correction action will actually remove the Primary Effect.
- Show that by not estimating the Management Dysfunction is removed.
None is this is in palce for the #NoEstimates conjecture that estimates are the smell of dysfunction.
So unless we have some understanding of the Dysfunction, conjecturing that estimates are the smell and the Not Estimating will remove the dysfunction has little chance of actual success.
No Estimates is a solution looking for a problem to solve. And to date that problem has not been identified, and most importantly the conjecture that Not Estimating fixes the problem has no tangible evidence to confirm it will fix the problem.
It is common to confuse strategy with operational effectiveness. Strategy for Information Technology (IT) projects contains three major themes. These form the foundation of the IT Strategy as well as the tactical processes that will be deployed in support of these strategies.
- Business improvements are enabled by Information Technology that is integrated not disintegrated. This integration must be horizontal versus vertical. Horizontal systems remove islands of information and build bridges between the business units. In this integrated system, multiple data sources are made transparent to the end users as well as the applications that utilize them.
- Information Technology requirements are always growing, changing, and being extended. The Information Technology is no longer static, but dynamic, adapting to the changing business requirements.
- Information Technology is about abstractions. If hardware, software and data were the only foundations of a system, then Information Technology would not be able to keep pace with the business requirements. Instead, business processes, objects and services are the foundation of the system, which then drives the business process in their adaptation of the changing market forces.
What Is Strategy?
Strategy is creating fit among a company’s activities. The success of a strategy depends on doing many things well – not just a few. The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions. When this occurs operational effectiveness determines the relative performance of the organization. 
Improving operational effectiveness is a necessary part of management, but it is not strategy. In confusing the two, managers will be unintentionally backed into a way of thinking about the business environment that drives the business processes (IT) away from the strategic support and toward the tactical improvement of operational effectiveness.
Managers must be able to clearly distinguish operational effectiveness from strategy. Both are essential, but the two agendas are different. The operational effectiveness agenda involves continual improvement business processes that have no trade–offs associated with them. The operational effectiveness agenda is the proper place for constant change, flexibility, and relentless efforts to achieve best practices. In contrast, the strategic agenda is the place for making clear tradeoffs and tightening the fit between the participating business components. Strategy involves the continual search for ways to reinforce and extend the company’s position in the market place.
The concept of fit among functional units is one of the oldest ideas in strategy. Gradually however, it has been supplanted with newconcepts of corecompetencies, criticalresources and key success factors. In fact fit is far more critical to the success of the IT systems than realized.  Strategic fit among the various systems components and the business processes they support is fundamental not only to competitive advantage but also to the sustainability of that advantage.
Fit among a company’s activities creates pressures and incentives to improve operational effectiveness. Fit means that poor performance in one activity will degrade performance in others, so that weaknesses are exposed drawing management’s attention. Conversely, with increasing fit, improvements of one activity will pay dividends in other areas.
The challenge now is to create fit among the IT components and their matching business components.
Building A Strategy
To define our Vision, Strategic Objectives, Performance Goals, Critical Success Factors in achieving those, and the measures of effectiveness and performance in pursuit of those strategic goals and objectives, we need a method that collects all of these in a single place.
If we are going to make tradeoffs in pursuit of strategy, we need to know what those tradeoffs are, how much will be the opportunity cost for each trade and how each trade impacts our strategic decision making.
To dive into the details, to make those opportunity cost tradeoffs about future outcomes in the presence of uncertainty we must of course ESTIMATE. There can be no execution of the strategy without make estimates of the benefits of the outcomes of the project that delivers the capabilities that implement the strategy.
The Balanced Scorecard presentation below shows how to build the strategy. Page 49 - 52 shows how to connect the dots between strategy and project execution, where the work is done, at or below the planned cost, on or before the needed time, and with the planned effectiveness and performance of the delivered capabilities. Showing up late, over budget, and with missing capabilities will not enable the strategy to fulfill it's mission and vision. It's a closed loop system - all parts must work in combination for success.
 “What is Strategy,” M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61–78.
Jack Welch Speaks: Wisdom from the World’s Greatest Business Leader, J. Welch and J. C. Lowe, John Wiley & Sons, 1998.
Control Your Destiny or Someone Else Will: Lessons in Mastering Change–From the Principles Jack Welch Used to Revolutionize GE, N. M. Tichy and S. Sherman, Harpers Business, 1994.
How do you manage to communicate about your project with virtually no marketing budget? This was a question someone asked me after my presentation on how to market your project at the 2015 PMXPO event.
We don’t all have big budgets to produce banners, T-shirts and mugs with logos on to share the messages about our projects. You do? Oh, good for you. Go and read this about the collaboration software you can use on your projects.
If you are still here, then you don’t have a big budget for project communications. You are in the majority. So let’s look at what options you have for cheap or free project marketing.
Cheap project communications ideas
There are lots of things you can do for free or for very little money (if you don’t count the time spent):
- Email newsletters
- Intranet sites
- Meeting people and buying them coffee
- Town Hall style meetings
- Quizzes – these are surprisingly popular and only need a small token prize
- Using your team as ‘marketing outreach’ people to spread the message.
Use the skills you have. I once roped in my entire family to make 160 ‘thank you’ labels to go on bottles of wine (which the project had paid for). We sat on the floor in the living room, cutting out labels, punching holes, decorating them, cutting and tying ribbon to hold them on. Then one of my colleagues hand-wrote ‘thank you’ on all of them and put them on the bottles one evening. When we came to give them out, we invited each recipient to select either red or white from the wine in boxes. They all took off the label and left it in the box. No acknowledgement of our hard work or the personal touch we had tried to hard to show.
Lesson learned: for that group of stakeholders, just give them the alcohol! (We did have some alternatives for non-alcohol drinkers, because we’re that kind of thoughtful project team.)
Cheap i.e. craftily making all the thank you labels ourselves didn’t have the impact I thought it would but on the other hand if I’d spent a lot of money getting labels printed it would have felt much more wasted.
I have also crocheted a desk ornament as a prize for a project competition. I’m not sure that the recipient was particularly grateful (he would have probably prefered a bottle of wine) but it showed personality and was fun for me to do.
Food as a communication tool
Another cheap thing to do is to get rice paper logos printed and then use them as cake toppers. I did this for the pilot launch of a new piece of software. I was able to offer cakes to the first users with pictures of the office building on the top, and some with the company logo. In hindsight, photos of people would have been more interesting.
Tip: Don’t put the rice paper toppers on the cakes the day before. The ink leached into the icing and the pictures weren’t that clear. For best results, stick them on just before you bring them out.
Cakes, crochet, wine… these ideas reflect my personality and the leadership style I bring to my projects. You might be different. Tap into your interests and those of the team.
Video production is a lot cheaper these days, and people are much more forgiving of dubious quality. You don’t have to have any special skills. Give it a go on your tablet or phone and record your project sponsor explaining the vision. It can be a really powerful (and cost-effective) way of sharing the key messages about your project without them being diluted by operational managers re-telling the story to their staff.
Some video tips:
- Shoot in natural light. If you don’t have studio lights, natural is better. Think big windows or outside.
- Don’t shoot into the light. Don’t position your interviewee directly in front of the window.
- Audio quality matters. If they can’t hear what the person on screen is saying then this undermines your whole effort to communicate effectively. Minimise background noise.
- Do a screen test. Take a short video, then play it back. Show the person what they look like on screen (many people are worried about this). Check the background and audio quality. Move any distracting background items and make sure that it doesn’t look like a pot plant is growing out of their head or anything.
I use this this video camera* and an external microphone but I have also used my iPad and no microphone in a quite room. They both work fine for the type of quality I’m prepared to go for.
I mainly use Camtasia to edit my video and add text overlays to show who is speaking but lately I’ve done a few using the YouTube video editor and that is pretty good too.
Get a bigger budget
The best way to manage your project budget for communications is to get a bigger budget. You might not know what you want to do at the start of your proejct but you can guarantee you’ll be doing something.
Put some money aside when you create your project budget for communications. Even a small amount can be useful to handle the unexpected costs of having to hire a meeting room to give a presentation to key stakeholders or something like that.
Talk to your project sponsor when the project begins and explain why it’s so important to share positive messages about your project. A reminder: it’s because:
- You need people to engage – and engage properly, not just nodding.
- To do that they have to understand what you are doing.
- Then they need to want to be part of it.
- Because that reduces resistance to change and increases the chance of successful adoption and therefore getting the benefits in the business case.
Your project sponsor will want success – if they don’t, you shouldn’t be doing the project at all. Good communications is part of the drive for success, and if your sponsor doesn’t get that then they aren’t a very good sponsor.
If you can’t get any money put aside for project marketing activity then hopefully the ideas here will at least give you some free and low-cost suggestions for creating engaging communications on your projects.
* This article contains affiliate links at no cost to you.
With the principles of Capabilities Based Planning in place from the previous post, here's how to implement it.
The key here is to have a capabilities delivery map in place showing what capabilities need to be delivered in what sequence for what cost to enable the business to receive the planned value in exchange for the cost to produce those capabilities.
Here's an actual example for capabilities delivery. Each capabilities arrives with its dependent capabilities to provide the needed value to the business. This value enables the bsuienss to do something of value in support of the business strategy and the planned revenue that results from the cost to produce that value
Over the years the success rate of traditional project management methods applied to software development projects has been underwhelming. Traditional project management methods are based on a retrospective approach, which measures variance against plan rather than providing a performance–forecast that can be used to guide projects in a chaotic environment.  There are a number of programmatic control issues associated with IT projects that suggest a better approach is needed. 
Using this linear project planning paradigm – sometimes referred to as waterfall – but often derived from PMBOK linear style planning processes – there is little attention given to the forces that negatively impact the project. These project risks have no means of evaluation other than to acknowledge their presence, define mitigations and track the results. The impact on the business value of the capabilities of the system is not part of the project management process.
Capabilities Based Planning is anchored on producing Enterprise and Software Intensive Systems focused on strategic outcomes. Progress is measured through assessment of the effectiveness and performance of the deliverables in meeting those strategic objectives. This approach assures business value is connected with the strategy not just measures of the passage or time and consumption of money and the production of technical features.
In this approach avoiding or controlling change becomes the primary activity of project management. In this traditional model change is undesirable. In reality of business systems development, change is not only natural it is desirable. It is through change that the system can adapt to the needs of the business, which are themselves driven by external forces. These forces are rarely under the control of the project manager let alone the senior management of the business.
One project failure mode is when the participants and leaders of the project fail to recognize the difference between managing in the presence of change and managing change. It is managing in the presence of change that is a critical success factor of any modern business systems development.
Definition of Capability-Based Planning
“… involves a functional analysis of operational requirements. Capabilities are identified based on the tasks required… Once the required capability inventory is defined, the most cost effective and efficient options to satisfy the requirements are sought.”
What Are Capabilities and Why Are They Better at Describing Maturity?
Measuring project and product maturity as a function of effort and time assures that project management adds value to the business. Simply controlling and measuring the expenditure of resources – score keeping – provides little value in the presence of change. We need measures in units meaningful to the decision makers. Physical Percent complete needs to be measured as increasing Effectiveness and Performance, with decreasing Risk to increase the Probability of Project Success.
Capabilities–based planning provides a defined outcome that is not a final conclusion but lays the groundwork for the continued delivery of value. Objectives are reached and the operational value delivered when a defined capability is available for use. Features and functions describe the static and dynamic behaviors of a system, but they are not directly connected to the business strategy. Milestones indicate that a position in a timeline has been reached, but do not forecast what value will be delivered to the business or how this value is traceable to the needs of the user community. Capabilities provide the answer to the following question: in order to achieve our objectives, what capabilities must we possess? 
Capabilities–based planning transforms the delivery of features and functions into the delivery of processes that support a business strategy. Capabilities–based planning is planning, under the conditions of uncertainty, to provide capabilities suitable for a wide range of business challenges and circumstances, while working within an economic framework. This approach emphasizes flexibility, adaptiveness, and robust capabilities, implying a modular building–block approach to the delivery of enterprise applications.
Capabilities are not the same as features and functions; they enable demands to be met without explicit specification of the solution. A capability is the ability to affect an outcome, react to an input, or change an effect.
A capability provides an outcome or an effect without an a priori specification. Features and functions require an a priori specification in order to test for their existence or conformance to the specification. Capabilities–based planning can be understood at the execution level, but it needs to be raised to the level of enterprise process analysis:
Identify a needed capability in operational terms, using the set of capability options to assess the effectiveness in an operations paradigm, and make choices about requirements and the ways to achieve the capability using an integrated portfolio framework to produce an output set of options based on these operational paradigms.
Putting capabilities–based planning to work requires a change in our approach to planning — a set of business process improvement activities focused on assessing increasing maturity of the capabilities needed to fulfill the strategic objectives. Emphasis is placed on operational capabilities rather than features and functions. These operational capabilities become the building blocks of change. The emphasis is also placed on evaluating capabilities under conditions of uncertainty, which requires the deployment of robust building blocks capable of adapting to these changes. In both cases, analysis illuminates the feasibility of alternatives.
Augmenting Our Strategy–Making with Capabilities
Strategy–making is the starting point for project management. It asks and answers the question why are we doing this? Strategy making activities can be augmented through a capabilities–based planning process by mapping strategies to the assessment of maturity evaluation points for each of the emerging capabilities. This approach connects the why of a project with the how. The result is the replacement of the measurement of progress as the passage of time with the measurement of progress as the delivery of capabilities.Capabilities–based planning focuses on assessing the increasing maturity of functionality defined by the strategy. Planning under uncertainty provides capabilities suitable for a wide range of challenges and circumstances while working within an economic framework that necessitates choice, where the focus is on “possible uses” rather than specified features and functions.
With a set of capabilities in mind, a plan for delivering the capabilities is needed. One approach to building this plan is an Event–Based integrated master schedule. This has been discussed in the past, but the next article will describe the details on how to build such a schedule; derived from the capabilities.
 “Uncertainty and Project Management: Beyond the Critical Path Mentality,” Arnoud de Meyer, INSEAD Working Paper, 2001.
 “Analytical Architecture for Capabilities–Based Planning, Mission–System Analysis, and Transformation,” Paul K. Davis, RAND National Defense Research Institute, MR–1513–OSD, 2002.
There's a popular meme going around that asking for estimates and making estimates is the smell of dysfunction. We can assume it's management dysfunction. So what are the dysfunctions of management that they ask for estimates from those spending their money to produce value in exchange?
Turns out there a few obvious ones, when we consider Dilbert-style management.
- Commitment to a probabilistic number as if it were a point number.
- Punishment of developers for not meeting their estimates?
But this is bad management. Obvious to everyone who has ever attended a probability and statistics class in their engineering, computer science, or hard science education.
So maybe the first dysfunction is those conjecturing estimating is the smell of dysfunction is they don't understand the underlying mathematics of making estimates in the presence of uncertainty. This includes both management and those spending the money provided by management.
Since there is no domain, context, framing assumptions, or principles stated by those conjecturing estimates are the smell of dysfunction let's look at one set of principles of writing software for money - other peoples money.
If we look for the root cause of projects going wrong, let's see how not following the 5 Principles can be a source of the dysfunction.
What Does Done Look Like?
Is there some notion of what capabilities the customer - those paying - need when we're done spending their money? Is there some units of measure of Done that are meaningful to those paying? If the answer is no, then we're likely to have little value for estimates, no matter the quality of the estimate.
The smell of dysfunction is proceed to spend money without knowing what done looks like in any meaningful units of measure for those providing the money
What's the Pathto Done?
Do we have any notion of the order of work to be performed? Let's assume there is some dependency in this work. The agile notion of INVEST must be tested first. Any non-trivial project has interdependencies. If there are non, then the work must be simple enough that all the pieces act independently from each other. No order of production, no order of operations, no order of use.
The smell of dysfunction is not having a strategy to reach done on of before the need date for the capabilities that will earn back the investment for the money provided by those paying for your work.
Do We Have Enough Resources to Get to Done?
We need time, money, and resources to produce business value in exchange for the money we've been given. How much money? How much time? What resources?
The smell of dysfunction is not knowing how much of work will cots in the end to some level of confidence. Not knowing when we'll be done to some level of confidence. Our not knowing of what we've been asked to produce for that money and time will actually provide the needed capabilities those paying are expecting.
What Impediments Will We Encounter Along the Way?
All projects have uncertainty. Uncertainty produces risk. Managing in the presence of uncertainty means managing in the presence of risk.
Risk Management is How Adults Manage Projects - Tim Lister
Uncertainty comes in two forms reducible (epistemic) and irreducible (aleatory). Reducible uncertainty and its associated risk can be bought down. How much risk, what is the cost to buy it down? That means estimating.
Irreducible uncertainty and its associated risk cannot be bought down. We need margin - cost margin, schedule margin, technical margin to protect the project from this unfavorable outcome. How much margin? We need an estimate. For both reducible and irreducible uncertainty answering that question comes easily with a Monte Carlo Simulation.
The smell of dysfunction is not having a risk model for all the project work. Not have estimating for the probability of occurance of an event based risks. Not have a Probability Distribution Function of of the naturally occurring variance of irreducible work - duration, cost, performance.
How Are We Going To Measure Progress to Plan?
To measure progress we need a plan. Then we need some assessment of phsycal percent complete. This measurement is an ideal paradigm for agile. Working productsthat meet the measures of effectiveness, measures of performance, technical performance measures, ley performance parameters are ways to assure what we produced actually does what is needed by those who are paying.
To start with a target to steer toward we need to estimate what are the possible outcomes of the project. That is what are the achievable goals in measures of Effectiveness and Performance. With this starting point and measures of actual performance we can create a error signal used to Close Loop Control to tag corrective actions to steer toward our target. The target can change of course, and many time does.
With the probabilistic target and the actual measurement we have an Open Loop Control system, which provides no steering signal and results in we'll be done when we're done, we'll spend what we spend, and you'll get what you get,. Could be better than planned, could be worse than plan - don't know.
The smell of dysfunction is to not have a probabilistic steering target developed from past performance and models of future performance. Without this model we are operating open loop. Not steering target that can be corrected with actual performance information., But more importantly not steering target telling what our performance must be to meet the business goals of the project.
So Want To Talk About Smells?
Tangible evidence of dysfunction is needed. Variance analysis needed. Tangible corrective actions needed.
Exploring is none of these. Exploring is talking about fixing the smell. Talking and exploring doesn't fix the dysfunction. Looking for waste in the Muda sense - this is Muda. Do something tangible. Measure the result. Compare to plan. Make corrections to both action and plan - closed loop. Repeat till success.
Stop exploring - do something constructive. Correct the dysfunctions with actionable outcomes.
In The End
Conjecturing to NOT do something without first identifying the root cause of the smell is Open Loop decision making.
Conjecturing to NOT do something without saying what that something is so it can be tested is of little value to those paying money that need real help to increase the probability of success of their work efforts.
Conjecturing to explore has little value to those seeking actionable corrections to the problems. Exploring means o real commitment to improve. We're just wandering around looking under rocks for interesting ideas. Having someone pay for that is called pure research. Business that produces products and services in exchange for money are looking for value to result from their investment.
Today I’m interviewing Mark Woeppel, author of Visual Project Management*. It’s an interesting title that I thought was worth explaining, so let’s dive in.
Mark, what is visual project management?
Visual Project Management is a process that uses the visualization of the project delivery process to drive team behaviors: to collaborate and effectively manage projects to deliver on time. VPM treats project execution as a process, with principles and practices to create repeatable, scalable results.
OK, thanks. Why do you think projects are still late and over budget when professional project management techniques have been around for years?
The main emphasis of the project management body of knowledge is “control”, which typically means more or better planning. Very little of the body of knowledge is devoted to execution. There are assumes that with a plan, the outcome will match. Project managers are quite good at achieving scope, but not managing the schedule.
Peter Drucker said, “…the word ‘controls’ is not the plural of the word ‘control’”. Making a detailed plan doesn’t give real control; it gives the illusion of control. What provides control is having an understanding of the interdependencies of the work and having the flexibility to respond when the real world presents the team with the unexpected.
So let’s talk about the unexpected. How can project managers identify the early warning signs of a project at risk of late delivery?
Rather than look at the project plan, look at what the team is doing. How flexible are they? Do they respond quickly? Decisively? In general, how are they responding to the day to day realities that are presented to them?
This will give you a sense of how “in control” the project is, and therefore, the likelihood of a predictable outcome.
Also look for:
Lack of visibility. Without clear situational awareness, the team will flounder. There will be plenty of activity, but little progress.
The team spends a great deal of time working to understand where they are in the project and the next steps to advance it. The path to project completion is not clear. The critical path to completion is either not identified or unclear. Project meetings are spent sorting out what has been done and negotiating priorities.
Lack of engagement. Many times, the only person who is actually on the project is the project manager. The project manager must then spend their time on team enrollment activities, rather than the core task of moving the project ahead.
The members of the “team” are not fully engaged with work of the project. They don’t respond to questions quickly, don’t come to meetings, are not working with the rest of the team to move the project forward. It’s hard to find or discover the people that are accountable to solve problems.
Shifting priorities. When priorities are changing, more work is added to the project, time and productivity are lost, and the project is delayed.
The project team members are spending their time sorting through the work to determine which tasks should have the highest priority. They’ll be switching – changing priorities for the resources (people) doing the work of the project. New information causes frequent changes in priorities.
Wandering bottlenecks. There is always a constraint that limits the rate at which the project can be completed, but if it’s always moving from week to week or day to day, it indicates a poor grasp of the resource requirements to complete the project.
Sometimes disguised as a priority problem, the team will be chasing resource shortages. There never seems to be enough of the right resources at the right time. The team may feel a little like they’re playing resource “Whack-A-Mole”.
As teams master the basics of execution, they’ll be able to integrate a well-constructed plan with the understanding of variation to monitor the critical chain and manage a time buffer to know the probability of delivering on time throughout the life of the project. Few teams are there yet.
That sounds like a powerful formula. Do you have any examples you can share?
There are many examples in the book, but I think the best examples come from those that decide to transform their project delivery process, rather than rescue a specific project. It’s in these examples that we can gather multiple results from multiple project completions.
- In a technology services organization, they more than tripled productivity and improved on time delivery by 20% in less than 3 months.
- In a software development organization they increased productivity by more than 500% and achieved 100% release date achievement.
- In a new product development process, FMC Technologies tripled engineering productivity and reduced lead time by 70%.
What’s the one thing you wish all project managers did that would improve projects forever?
Project managers should think of project delivery as a process and take ownership of the ENTIRE process. They become process improvement professionals, rather than task masters.
Successful project execution is a process. It has a set of principles you can learn, apply, and repeat. I hope that by sharing these, readers will adopt them and see the same success our customers and our team has seen. Life in project management need not be a chore, it can be a rewarding experience.
I certainly don’t feel that project management is a chore. Thanks, Mark, for sharing your thoughts.
* This post contains affiliate links at no cost to you.
Populist books provide an important role in the processes of "thinking about things." They are simple, understandable in ways that resonant with the those not familiar with a topic, and are hopefully gateway sources to then next level of understanding. Populist books have a down-side as well. They are usually simplified versions of the underlying topic, devoid of the details, which unfortunately have mathematics that may be beyond the casual reader.
I've written about the issues with populist books before. There is a new set of issues that needs to be addressed. The Think Fast Act Slow book is a recent example of a populist book. It has useful materials, but leaves out all the ground work and heavy lifting needed to put these ideas to work.
In graduate school, there are several things you learn before starting your thesis work. Do a literature search. You're bright idea may have already been done. Or worse your bright idea is a cockamamy idea on day one. If everyone tells you it's a cockamamy idea, you may be able to show the world they're wrong. To do that you need to get through a peer review and a test of your idea by strangers using actual data that holds up to ruthless testing by others. There have been a few of those, most have gone on to win the Nobel Prize.
So if you hear some idea that doesn't quite make sense, ask for the data that supports that idea, so you can do independent testing. Better yet if that idea is an obvious violating of the basic principles - either of physics (cold fusion) or of economics (#NoEstimates) ask those proposing the idea for direct evidence of its applicability that can also be independently tested.
Here's a list of supporting papers need to put the populist ideas to work from my library. Goggle will find these for you:
- Anchoring and Adjustment in Software Estimation, Jorge Aranda and Steve Easterbook
- Judgement under Uncertainty Amos Tversky and Daniel Kahneman
- The Fragile Basic Anchoring Effect, Noel Brewer and Gretchen Chapman
- The Anchoring-and-Adjustment Heuristic Nicholas Epley and Thomas Gilovich
- Review of Tversky and Kahneman (1974): Judgement under uncertainty: Heuristics and Baises
- Reference points and redistribution preferences: Experiment evidence, Jimmy Cjarrité, Raymond Fisman, and Ilyana Kuziemko
- Availability: A heuristic for judging frequency and probability, Amos Tversky and Daniel Kahneman
- Attention and Effort, Daniel Kahneman
- Assessing Range of Probabilities, Strategic Decision and Risk Management, Stanford Certificate Program, Decision Analysis for the Professional, Chapter 12.
- Anchoring Unbound, Nicholas Epley and Thomas Gilovich
- Anchoring and Adjustment in Software Project Management: An Experimental Investigation, Timothy Costello, Naval Postgraduate School, Monterey, California
These are a small sample of the background that needs to be examined after read the populist book.
With this example, you can move beyond populist ideas - no matter how valid - to technical ideas and start putting them to work and testing the outcomes for their efficacy in your domain.
Here's a starting point for that effort in Populist versus Technical View of Problems