It’s a copy of Laura Brandenburg’s book, How to Start a Business Analyst Career*. It’s a comprehensive guide to everything you need to know to get started working as a business analyst. Learn to apply business analyst techniques, select requirements training, and explore job roles so you can choose what’s right for you.
To enter, get in touch using the contact form with the phrase “BA careers are Ba-rilliant” and I’ll enter you in the draw. Yes, I do make up weirder and weirder phrases for you to quote every month. I think it’s fun. The giveaway closes at 5pm UK time on Friday 10 July 2015.
This book is worth nearly $40 so it’s a great prize.
Don’t delay, enter here today!
Normal giveaway rules apply – read them here.
* This post contains affiliate links at no cost to you.
This article has kindly been sponsored by Celoxis and is written by Sanket Pai.
Enterprise software has traditionally been related to its ability to solve a specific purpose or a business problem. Be it ERP, CRM or Accounting, enterprises have typically chosen specific ‘best-in-class’ solutions to address specific organizational processes. Businesses end up with several ‘best-in-class’ solutions, each tailored to address a particular business challenge in the best possible way.
Time and again this has only proven to also bring in a number of problems that impact productivity, quality and subsequently the ROI and business top lines.
According to the 2013-14 Key Trends in Software Pricing & Licensing Report, almost all organizations are wasting money on software that isn’t being used. This is known as ‘shelfware’. Ninety-six percent say that at least some of the software they’ve purchased is shelfware. A significant percentage (39%) reports that 21% or more of their enterprise software spend is wasted on shelfware.
At the same time that so much waste is being reported, funds are growing scarcer. Almost two-thirds of enterprises (63%) say their software budgets will either stay the same or shrink over the next two years.
Software decision makers often substitute ‘best-fit’ with ‘best-in-class’ which often leads to this deluge of spending.
Are you spending money on enterprise systems that you don’t fully use? Let’s look at some of the factors that contribute to the above scenario.
Learning curve and adoption
Enterprise projects today demand multiple skills and multiple work assignments across multiple location teams and time zones. When teams are expected to use multiple tools for various aspects of work, their proficiency with the tools becomes a crucial factor. Best-in-class tools pack in a lot of features to ensure they address the specific need in every way. They wouldn’t be best-in-class otherwise, would they?
This leads to a complex user experience. Learning curves get a lot steeper and adoption rates start going southwards. Not an ideal scenario for an organization that has spent significant amounts on software procurement, implementation and training.
Just think about the time spent by employees completing information in multiple tools on a daily basis. Add it up over a period and what you get is a significant productivity leak.
In most cases, there are overlaps and employees end up filling in the same information in more than one tool. It is ironic that the very tools that are supposed to automate processes and save time end up being productivity killers.
Speed of information
This is the age of information. Teams, managers, stakeholders and customers rely on real time information and insights to make crucial business decisions. To enable this, there has to be a seamless exchange of real time information between the various systems in use.
The reality however is far from ideal. Most best-in-class systems don’t come with plug and play integration or need a fair bit of customization. That only means more time, effort and investment.
Non-availability of real time information can have a huge impact on visibility into health of projects, processes, resources and financials.
Procuring multiple best-in-class solutions comes with its own vendor management challenges. Depending on their scale of operations, companies could end up managing anywhere between a 10 to hundreds of vendors across the board.
Irrespective of the number of vendors, multi-vendor management is often complex, time consuming and obviously very expensive. Apart from the procurement cost, companies need to spend a significant amount on overheads and infrastructure to support the different contract types. Add to that the time and energy spent on managing service levels and support across all vendors. A multi-vendor scenario often leads to creation of new inefficiencies, proliferation of which will lead to incremental costs and negative impact on ROI.
The alternative: ‘All in One’, comprehensive and hybrid tools
The shift from ‘best-in-class’ multiple tools to comprehensive ‘all-in-one’ tools is gaining momentum.
However, once you have decided to go for a comprehensive tool, it is important to put some thought into picking the right one.
Here are the seven criteria that highly improve your probability for a successful comprehensive software deployment.
- The business need:Defining the business need or problem accurately is half the battle won. Conducting a detailed requirement analysis should be the first step in software procurement exercise. The selected tool should be able to address the exact business need and adapt to the environment.
- User Experience:Purchase is an executive decision, but the ROI depends on adoption across the organization. User experience is critical to driving and sustaining adoption. Organizations should therefore consider feedback from users on user experience of potential tools before taking the decision.
- Service Levels:Organizations should get a grip on post purchase scenarios such as uptime, technical support and training. Online user forums could be valuable when it comes to understanding community grievances.
- Data security:Most of the comprehensive software tools come with a free test drive. Be sure to demand for one, if not readily available. Conduct a data security audit in this trial period to ensure that the tool complies with organizational guidelines. This is absolutely critical, especially with your customer and/or financial data.
- Vendor credibility:To ensure that the long term objectives of the investment are safeguarded, it is important to verify the credibility of the vendor. Organizations can accomplish this by conducting reference checks and getting insights into their reliability and customer satisfaction.
- Integration:It is important that the tool integrates well with your existing business applications and that it provides the architecture to integrate with other tools in future. These aspects need to thoroughly tested in the trial phase so that there are no surprises post purchase.
- ROI measurement:To justify the investment, executives will need to figure out the ROI measurement beforehand. They will need to keep a close eye on factors such as productivity, impact on quality and immediate & long term cost savings among others.
To stay competitive in this ever evolving and tough business environment, enterprises are constantly looking to be more efficient and effective. The shift from ‘best-in-class’ multiple tools to comprehensive ‘all-in-one’ tools is gaining momentum and it is time enterprises and software vendors geared up for this big shift.
About the Author:Sanket Pai is currently heading the Customer & Product Experience team at Celoxis, an enterprise-class comprehensive project management software, available on-premise or via the cloud. His interests lie in Product Management, Business Analysis, Innovation Management, Customer Insights, Research and Experience through Design Thinking pedagogy and application of Business Design. You can also follow him on Twitter or LinkedIn.
Making decisions in the presence of uncertainty of a future outcomes resulting from that decision is an important topic in the project management, product development, and engineering domains. The first question in this domain is...
If the future is not identical to the past, how can we make a decision in the presence of this future uncertainty?
The answer is we need some means of taking what we know about the past and the present and turning it into information about the future. This information can be measurements or actual activities, models and simulation of past and future activities, reference classes, parametric models, If the future is identical to the past and the present, it's a simple straight line projection from the past to the future. But there are some questions:
- Is the future like the past? Have we just assumed this, or have we actually developed an understanding of the future?
- If so, can that future be sustained long enough for our actions to have a beneficial impact?
- If not, what is the statistical behavior in this future and how can we discover this behaviour?
The answers to these and many other questions can be found in the mathematics of probability and statistics. Here's some popular misconceptions of mathematical concepts
Modeling is the Key to Decision Making
"All models are wrong, some are useful," George Box and Norman R. Draper (1987). Empirical Model-Building and Response Surfaces, p. 424, Wiley. ISBN 0471810339.
- This book is about process control systems and the statistical process models used to design and operate the control systems in chemical plants. (This is a domain I have worked in and developed software for).
- This quote has been wildly misquoted, not only out of context, but also completely out of the domain it is applicable to.
- All models are wrong says, every model is wrong because it is a simplification of reality. This is the definition of a model.
- Some models, in the "hard" sciences, are only a little wrong. They ignore things like friction or the gravitational effect of tiny bodies. Other models are a lot wrong - they ignore bigger things. In the social sciences, big things are ignored.
- Statistical models are descriptions of systems using mathematical language. In many cases we can add a certain layer of abstraction to enable an inferential procedure.
- It is almost impossible for a single model to describe perfectly a real world phenomenon given our own subjective view of the world, since our sensory system is not perfect.
- But - and this is the critical misinterpretation of Box's quote - successful statistical inference does happen any a certain degree of consistency we exploit.
- So our almost always wrong models do prove useful.
We can't possibly estimate activities in the future if we don't already know what they are
We actually do this all the time. But more importantly there are simple step-by-step methods for making credible estimates about unknown - BUT KNOWABLE - outcomes.
This know of unknown but knowable is critical. If we really can't know - it is unknowable - then the work is not a project. It is pure research. So move on, unless you're a PhD researcher.
Here's a little dialog showing how to estimating most anything in the software development world.
With your knowledge and experience in the domain and a reasonable understanding of what the customer wants (no units of measure for reasonable by the way, sorry), let's ask some questions.
I have no pre-defined expectation of the duration. That is I have no anchor to start. If I did and didn't have a credible estimate I'd be a Dilbert manager - and I'm not.
- Me - now that you know a little bit about my needed feature, can you develop this in less than 6 months?
- You - of course I can, I'm not a complete moron.
- Me - good, I knew I was right to hire you. How about developing this feature in a week?
- You - are you out of your mind? I'd have to be a complete moron to sign up for that.
- Me - good, still confirms I hired the right person for the job. How about getting it done in 4 months?
- You - well that's still seems like too long, but I guess it'll be more than enough time if we run into problems or it turns out you don't really know what you want and change your mind.
- Me - thanks for the confidence in my ability. How about 6 weeks for this puppy?
- You - aw come on, now you're making me cranky. I don't know anyone except someone who has done this already, that can do it in 6 weeks. That's a real stretch for me. A real risk of failure and I don't want that. You hired me to be successful, and now you're setting me up for failure.
- Me - good, just checking. How about 2½ months - about 10 weeks?
- You - yea that still sounds pretty easy, with some margin. I'll go for that.
- Me - Nice, I like the way you think. How about 7 weeks?
- You - boy you're a pushy one aren't you. That's a stretch, but I've got some sense of what you want. It's possible, but I can't really commit to being done in that time, it'll be risky but I'll try.
- Me - good, let's go with 8½ weeks for now, and we'll update the estimate after a few weeks of you actually producing output I can look at.
Microeconomics of Decision Making
Making decisions about the future in the presence of uncertainty can be addressed by microeconomics principles. Microeconomics is a branch of economics that studies the behavior of individuals and small impacting organizations in making decisions on the allocation of limited resources. Projects have limited resources, business has limited resources. All human endeavors have limited resources - time, money, talent, capacity for work, skills, and other unknowns.
The microeconomics of decision making involves several variables
- Opportunity cost - the value of what we give up by taking that action. If we decide between A and B and choose B, what is the cost of A that we're giving up.
- Marginal cost analysis - impact of small changes in the “how-much” decision.
- Sunk cost - costs that have already been incurred and cannot be recovered.
- Present Value - The value today of a future cost or benefit.
Formally, defining this choice problem is simple: there is a state space S, whose elements are called states of nature and represent all the possible realizations of uncertainty; there is an outcome space X , whose elements represent the possible results of any conceivable decision; and there is a preference relation ⪸ over the mappings from S to X. †
This of course provides little in a way to make a decision on a project. But the point here is making decisions in the presence of uncertainty is a well developed discipline. Conjecturing it can't be done simply ignores this discipline.
The Valuation of Project Deliverables
It's been conjectured that focusing on value is the basis of good software development efforts. When suggested that this value is independent of cost is misinformed. Valuation is the process of determining the economic value of an asset, be it a created product, a service, or a process. Value is defined as the net worth, or the difference between the benefits produced by the asset and the costs to develop or acquire the asset, all adjusted appropriately for probabilistic risk, at a given point in time.
This valuation has several difficulties:
- Costs and benefits might occur at different points in time and need to be downward adjusted, or discounted, to account for time value of money: the fundamental principle that money is worth more today than in the future under ordinary economic conditions.
- Not all determinants of value are known at the time of the valuation due to uncertainty inherent in the environment.
- Sometimes intangible benefits such as learning, growth opportunities, and embedded flexibility are the dominant sources of value under uncertainty.
The valuation of the outcomes of software projects depends on the analysis of underlying costs and benefits. A prerequisite for cost-benefit analysis is the identification of the relevant value and cost drivers. Both these elements are probabilistic in nature driven by underlying uncertainty - both reducible and irreducible.
In addition to measurable benefits and costs of the software project, the valuation process must consider uncertainty. Uncertainty arises from different sources. Natural uncertainty (aleatory or irreducible( directly relates to variations in the environment variables (e.g., the variation in the number of defects in a software product).
Parameter uncertainty relates to the estimation of parameters (e.g., the reliability of the average number of defects). Model uncertainty relates to the validity of specific models used (e.g., the suitability of a certain distribution to model the defects). There is a straightforward taxonomy of uncertainty for software engineering that includes additional sources such as scope error and assumption error. The standard approach of handling uncertainty is by defining probability distributions for the underlying quantities, allowing the application of a standard calculus. Other approaches based on fuzzy measures or Bayesian networks consider different types of prior knowledge. ‡
The Final Point Once Again
The conjecture we can make informed decisions about choices in an uncertain future can be done in the absence of making estimates of the impacts of these choices has no basis in the mathematics of decision making.
This conjecture of course is simply not true. Any attempt to show this can be done has yet to materialize in any testable manner. This is where the basic math skills come into play. There is no math that supports this conjecture. Therefore there is no way to test this conjecture. It's personal opinion uninformed by any mathematics.
† Decision Theory Under Uncertainty, Johanna Etner, Meglena Jeleva, Jean-Marc Tallon, Centre d’Economie de la Sorbonne 2009.64
‡ Estimates, Uncertainty and Risk. IEEE Software, 69-74 (May 1997), Kitchenham and Linkman and "Belief Functions in Business Decisions. In: Studies in Fuzziness and Soft Computing, Vol. 88, Srivastava and Mock
Decision making is hard. Decision making is easy when we know what to do. When we don't know what to do there are conflicting choices that must be balanced in the presence of uncertainty for each of those choices. The bigger issue is that important choices are usually ones where we know the least about the outcomes and the cost and schedule to achieve those outcomes.
Decision science evolved to cope with decision making in the presence of uncertainty. This approach goes back to Bernoulli in the early 1700s, but remained an academic subject into the 20th century, because there was no satisfactory way to deal with the complexity of real life. Just after World War II, the fields of systems analysis and operations research began to develop. With the help of computers, it became possible to analyze problems of great complexity in the presence of uncertainty.
In 1938, Chester Barnard, authored of The Functions of the Executive, and coined the term “decision making” from the lexicon of public administration into the business world. This term replaced narrower descriptions such as “resource allocation” and “policy making.”
Decision analysis functions at four different levels
- Philosophy - uncertainty is a consequence of our incomplete knowledge of the world. In some cases, uncertainty can be partially or completely resolved before decisions are made and resources committed. In many important cases, complete information is not available or is too expensive (in time, money, or other resources) to obtain.
- Decision framework - decision analysis provides concepts and language to help the decision-maker. The decision maker is aware of the adequacy or inadequacy of the decision basis:
- Decision-making process - provides a step-by-step procedure that has proved practical in tackling even the most complex problems in an efficient and orderly way.
- Decision making methodology - provides a number of specific tools that are sometimes indispensable in analyzing a decision problem. These tools include procedures for eliciting and constructing influence diagrams, probability trees, and decision trees; procedures for encoding probability functions and utility curves; and a methodology for evaluating these trees and obtaining information useful to further refine the analysis.
Each level focuses on different aspects of the problem of making decisions. And it is decision making that we're after. The purpose of the analysis is not to obtain a set of numbers describing decision alternatives. It is to provide the decision-maker the insight needed to choose between alternatives. These insights typically have three elements:
- What is important to making the decision?
- Why is it important?
- How important is it?
Now To The Problem at Hand
It has been conjectured ...
The key here and the critical unanswered question is how can a decision about an outcome in the future, in the presence of that uncertain future, be made in the absence of estimating the attributes going into that decision?
That is, if we have less than acceptable knowledge about a future outcome, how can we make a decision about the choices involved in that outcome?
Dealing with Uncertainty
All project work operates in the presence of uncertainty. The underlying statistical processes create probabilistic outcomes for future activities. These activities may be probabilistic events, or the naturally occurring variances of the processes that make up the project.
Clarity of discussion through the language of probability is one of the basis of decision analysis. The reality of uncertainty must be confronted and described, and the mathematics of probability is the natural language to describe uncertainty.
When we don't have the clarity of language, when redefining mathematical terms, misusing mathematical terms, enters the conversation, agreeing on the ways - and there are many ways - of making decisions in the presence of an uncertain future - becomes bogged down in approaches that can't be tested in any credible manner. What remains is personal opinion, small sample anecdotes, and attempts to solve complex problems with simple and simple minded approaches.
For every complex problem there is an answer that is clear, simple, and wrong. H. L. Mencken
This video, put together by the APM’s Women in Project Management SIG, showcases female project managers talking about their career choices. They are inspiring, and come from lots of different industries. 4m38, safe for work.
The hashtag for the diversity campaign is #APMdiversetalentcampaign – share your stories on Twitter.
The estimator's charter is not to state what the developers should do, but rather to provide a reasonable project of what they will do. - Tom DeMarco
Here's a few resource materials for estimating cost, schedule, and technical outcomes on software intensive systems. In meeting about managing risk in the presence of uncertainty below, it became clear we need to integrate estimating with risk, technical performance measures, measures of effectiveness, measures of performance, cost, and schedule.
- Quantifying IT Forecast Quality, J.L. Eveleen and C. Verhoef
- Cost and Schedule Uncertainty: Analysis of Growth in Support of JCL, Darren Elliott, Tecolote Research
- Software Cost Estimation Metrics Manual for Defense Systems, Bradford Clark and Raymond Madachy.
- Analysis of Empirical Software Estimation Models
- A Framework for the Analysis of Software Cost Estimation Model
There are 1,117 other papers and articles in the Software Cost Estimating folder on my server. These are just a very small sample of how to make estimates.
The notion that we can make decision in the presence of uncertainty in the absence of estimating (#NoEstimates) the outcomes of those decisions can only work if there no opportunity costs at risk in the future. That is there is nothing at risk for making a choice between multiple outcomes.
Long-time reader Jim Hurst got in touch to share his top project management tips, his list of things he wishes he could try to remember to help him do his job better. He says, “I’ve come to realise that I’ll never have the project management-role ‘nailed’ but am a better PM for knowing that and for being reflective.”
I can certainly relate to these suggestions (and I love anything that makes reference to NCIS). I see a lot of number 46! I hope you can too. Thanks, Jim, for letting me share the list.
Jim’s Golden Rules of Project Management (based on Gibbs, NCIS: “He who herds cats”)
- There can never be enough communication – communicate, communicate, communicate.
- You ALWAYS need a plan (fail to plan, plan to fail).
- EVIDENCE, EVIDENCE, EVIDENCE – “CSI project management”.
- Project MANAGE, don’t Project DO = doomed!
- Never make any assumptions = project kryptonite.
- Always check, check and check again. People forget.
- Don’t be late. Set the example and keep to it.
- Be reflective, even when you know no one else is.
- Be wary of the grinning salesmen. Don’t trust them!
- Get real commitment (quote/dates) from third parties.
- Accept sometimes you can be wrong and admit it.
- The rule of 5 W’s – why, why, why, why and why.
- Any overspends need to be agreed upfront.
- Project methodology AGNOSTIC, best of breed.
- Type up minutes/actions as soon as possible post-meeting or forget.
- Book meetings at least 3 months in advance.
- Check ALL booked meetings, rooms and attendees.
- Remember the historic projects feedback.
- Exist somewhere between the Dance Floor and Balcony.
- Manage the Meeting – one person talking/watch the clock.
- Always make time to listen and empathise.
- Be prepared – “semper paratus”.
- Don’t waste time, a PM’s job is never finished.
- Don’t put it off until tomorrow, scissor tackle today!
- It is your job to HELP people deliver.
- “You can lead a horse to water, but you can’t make it drink.”
- Make sure you can find stuff when you need it or you’ll waste time later.
- You never stop learning.
- When you think you know it all, you are further away than you have ever been to it!
- Concentrate on the things that matter – rule of 80/20.
- Don’t forget to say ‘well done, thank you’ – it costs nothing, literally.
- Focus on the original objective. Don’t get distracted.
- NO surprises are allowed. NO black holes.
- Perfect is the enemy of good – Voltaire.
- Time spent on contracts is time well spent!
- Don’t underestimate the value of ‘the architect’ – BA role.
- Always check your Outlook reminders or you’ll get chased up!
- If you can keep your head while all about you are losing theirs – R Kipling.
- Trust yourself, your experience and project to date, to hold the course.
- Get confirmation on minutes/actions before meeting.
- “If you haven’t planned it, you can’t control it.”
- Keep your eyes on the prize/ball!
- Best case scenario does not exist.
- ‘The 411’ or just the facts – Who, what, where, when, how and why.
- Find out the WIIFM or whiff em – what’s in it for me.
- A task is not done until it’s done. Avoid 90% syndrome.
- If everything is under control, go up a gear.
- It’s easy to see, harder to foresee.
- Don’t be afraid or too proud to ask for help.
- A project manager is only as good as his/her team. Defer to their experience/skills.
And a bonus quote:
- “Never eat more than you can lift” – Miss Piggy.
Hope you enjoyed that!
Our daughter is an elementary teacher in Austin Texas. A nice school, Number 2 school in Texas.
While visiting this week, we were talking about a new book a group of us are working on. While showing her the TOC, she said Dad we do all that stuff (minus the finance side) every day, week, month, semester, and year. It's not that hard. That's what we've been trained to do. OK, but talent, dedication, skill, and a gift for teaching helps.
Here's how an elementary school teacher sees her job as the Project Manager of 20 young clients.
- Plan before starting anything, it’s going to go wrong, so know that up front and be able to recognize the train wreck is coming and get out of the way.
- The plan is a strategy for the successful completion of the project.
- Without the plan, you don't know how to assess progress in terms meaningful to the decision makers. Measures of cost and schedule are measures of effectiveness. Measurers of stories produces, features delivered aren;t measures or capabilities produced.
- A Capabilities Based Plan is that measure. What capabilities doesn't the customer need to accomplishment the business case or fulfill a mission.
- In education Blooms Taxonomy with TLOs and ELO's define the capabilities the student will possess at the end of the course.
- Done is defined as possessing a capability to accomplish something.
- Write this down in units of Effectiveness and Performance
- Risk management is how adults manage projects - Tim Lister
- Adult supervision is the role of the teacher. Many times adult supervision of the role of the project manager.
- Resource planning is a critical success factor for all projects.
- Risk planning is planning. Planning is strategy.
- Apply good risk management to all activities on the project. Perform some formal sequence of risk management. Pick one. My favorite is the SEI Continuous Risk Management process
- Any good project manager can see trouble coming.
- Isolate the troubled parts. Assign them to separate teams. Have them fix the problem so the rest of the project isn't impacted by them
- Being prepared is the major attribute of project success.
- This means planning.
- Let's things emerge is nice of small non-trivial projects with low value at risk.
- Set the highest quality standards possible
- No whining, every one put your "big boy " pants on a do the work needed to get the job done.
- Have retrospectives.
- Look back for opportunities for improvement
- Do Root Cause Analysis to find out the "real" why things didn't work
- Have fun while still working hard
I’ve read another novel! Check me out. It was The Last Runaway* by Tracy Chevalier. I had a couple of long train journeys plus an evening where I decided just to sit on the sofa and read (which hasn’t happened since I was pregnant with my first son). It was fantastic, and it didn’t end as I expected: it’s always nice when a book has an element of surprise.
On to work-based reading.
I’m about halfway through Message Not Received by Phil Simon, which is something I’m hoping will inspire me for the second edition of Social Media for Project Managers (I’ve edited six chapters of fourteen so some way to go yet). It is very good, and not project-management-y particularly, just a decent read about workplace communications with examples and tips.
This one isn’t exactly reading, although there is a lot of content to read on screen. I’m part-way through the first module of the Brain Sensei PMP® Exam Prep Course (that’s my affiliate link – you’ll see why I’m recommending it in a moment). It was gripping from the beginning – I want to be the project manager who saves children from burning buildings and builds a castle to protect the future of my village.
It’s video training but it’s actually good and it makes me want to learn about process groups. Plus, there’s a test. I don’t know about you, but I always like to know how I am doing.
The first module, which is the project management overview, is free at the moment. If you’re about to embark on your PMP exam prep then you should check it out on the Brain Sensei website. If you can get over the fact that it’s proud of the great music and video you’ll be fine. I don’t really need to be told that I’m about to learn in “an entertaining way”.
New across my desk this month are
- Project Driven Creation by Jo Bos, Ernst Harting and Marlet Hesselink
- Visual Project Management by Mark Woeppel.
The authors of both those books were kind enough to send them but I haven’t had a chance to look at them properly yet. I’m particularly interested in Woeppel’s book as I don’t understand the title: the book’s description is about identifying root causes of project failure, turnaround for failing projects, simplifying communication and that sort of thing. I don’t get where the ‘visual’ comes into it, but the reviews on Amazon are good and I’m prepared to be enlightened when I do get round to reading it. Plus I’m hoping to review him later this year, so fingers crossed for that.
What about you? Got anything good on the go at the moment?
* This article contains affiliate links at no cost to you.
Mario Henrique Trentim’s book, Managing Stakeholders as Clients, takes a sales-focused view of stakeholder engagement. Complex sales have a lot in common with projects. Stakeholders might not know what they actually want, they take a long time to buy (i.e. conclude the requirements phase and/or reach the end of the project), and there are lots of decisions involved. Whether you agree with this concept or not, there is a lot of good stakeholder management information in this book outside of the link to the sales process.
Early on the book makes the connection between scope management and stakeholder management. Trentim points out that the sponsor/stakeholder wants the deliverable, not the reports and budget spreadsheets.
Stakeholders, he says, control important resources. You can only manage your project well if you can steer through the complexities of these stakeholder groups. He offers a four ‘ship’ approach to doing this.
Trentim’s 4 ‘ships’
The four ‘ships’ are:
- Sponsorship: Having the support of senior management
- Partnership: His way of describing teamwork; surrounding yourself with excellent people
- Leadership: No contemporary project management book seems to be written without a nod to this at the moment
- Citizenship: Values, sustainability, responsibility, morals, ethics.
“If you don’t have a good sponsor to support you with authority and resources (sponsorship), if you don’t treat your stakeholders as partners (partnership), if you don’t know how to lead and protect your team (leadership), and if you don’t live by your values (citizenship), you’ll probably fail your project. Or you might be very lucky if you have any success.”
The book is not written by a native English speaker and it shows. An editor might have helped but would also have chipped away at Trentim’s affable, conversational, writing style.
The trouble with stakeholders
Today, says Trentim, project managers have to deal with more stakeholders than before. He lists the typical project stakeholders as:
- The project manager, often, in my opinion the most important stakeholder.
- Clients and users
- Contractors and suppliers
- Hidden stakeholders
He also talks about people he calls ‘surrogate stakeholders’. These individuals stand in for the true stakeholders or stakeholder groups.
“For example,” he writes, “a team member can be a surrogate customer, in case you do not have direct access to the customer. This is usual when developing mass products like a cell phone. Marketing acts as a surrogate of potential customers to elicit requirements of the product.”
However, he cautions that if you rely heavily on surrogates you risk missing something because however good they are they aren’t the real user.
He goes on:
“The golden lesson for project managers is that the client is not the only real stakeholder to worry about. The project should add value for all the stakeholders, considering various dimensions like environmental, social, political, economic, etc. No matter if stakeholders are primary or secondary, internal or external, you have to pay special attention to key stakeholders, the ones that have significant influence upon or importance to the project.”
Spelling out stakeholder management
Chapter 6 largely covers a step-by-step stakeholder identification analysis and recording. Trentim suggests using CRM software or a database to keep track of stakeholders for large complex projects of long duration. He seems to prefer theses tools over spreadsheets but says that spreadsheets will work for smaller initiatives.
Importantly, he stresses the need to keep the information in those systems confidential. That’s essential, and one of the main reasons I would personally opt for my head or a notebook for stakeholder notes: no one wants your client to accidentally stumble across a file with your detailed analysis of their staff, warts and all.
The book includes a number of useful tools including some generic questions to ask stakeholders. There are also various suggestions for impact/power/influence type models for categorising your stakeholders. It is good to see a book offer the reader options instead of one fixed approach. This best-tool-for-the-job mentality runs through the book, which draws equally on PRINCE2 and PMBOK for tools and techniques as well as Lean and others.
Managing stakeholder expectations
Trentim talks at length about managing expectations and satisfaction, although perhaps not always in those terms. Chapter 7 discusses how you can uncover what is important to stakeholders, and Chapter 8 details communication techniques. Trentim points out that you can’t control internal informal communication so he recommends instead focusing on making sure that trustworthy information is flowing through those channels.
Stakeholders are not always right, and they don’t always have the right information about the project so be the source of information and clarity, he says.
One of the basic premises of the book is that you have to understand what clients (i.e. stakeholders) want because they might not. There’s a lot of stuff about requirements elicitation and change management.
Towards the end of the book there’s a lot of detailed information about team management, presented in a very pragmatic way. Within the space of a chapter or two you’ve got team building, motivational theory, leadership techniques and conflict management. It’s like there was so much to say he had to stuff the end of the book but he still manages to be comprehensive.
I really enjoyed it, probably because Trentim has similar views to me about the role of the project manager. It’s also a good, practical primer for anyone looking to ‘do’ stakeholder engagement with a lot of tools discussed. You may not find all the answers, but you’ll certainly get a starting point to enable you to go off and research the ones you want to use in more detail.
Sound good? Buy Managing Stakeholders as Clients on Amazon.
* This post contains affiliate links at no cost to you.
There was an interesting post on the #NoEstimates thread that triggered memories of our hiking and climbing days with our children (now grown and gone) and our neighbor who has summited many of the highest peaks around the world.
The quote was Getting better at estimates is like using time to plan the Everest climb instead of climbing smaller mountains for practice.
A couple background ideas:
- The picture above is Longs Peak. We can see Longs Peak from our back deck in Niwot Colorado. It's one of 53 14,000 foot mountains in Colorado - Fourteeners. Long is one of 4 along the front range.
In our neighborhood are several semi-pro mountain climbers. People move to Colorado for the outdoor life, skiing, mountain and road biking, hiking, and climbing.
Now to the Tweet suggesting that getting better at estimating is replaced by doing (climb) smaller projects. Turns out estimates are needed for those smaller mountains, estimates are needed for all hiking and climbing. But first...
- No one is going to climb Everest - and live to tell about it - without first having summited many other high peaks.
- Anyone interested in the trials and tribulations of Everest should start with John Krakauer's Into Thin Air: A Personal Account of the Mt. Everest Disaster.
- Before attempting - and attempting is the operative word here - any signifiant peak several things have to be in place.
Let's start with those Things.
No matter how prepared you are, you need a plan. Practice on lower peaks is necessary but far from sufficient for success. Each summit requires planning in depth. For Long's peak you need a Plan A, Plan B, and possibly a Plan C. On most of all you need strong estimating skills and the accompanying experience to determine when to invoke each Plan. People die on Longs because they foolishly think they can beat the odds and proceed with Plan B.
So the suggest that summiting something big, like any of the Seven Summits, without both deep experience and deep planning is likely going to not be heard of again.
So the OP is likely speaking for not having summited much of anything, hard to tell, no experience resume attached.
The estimating part is basic, Can we make it to the key hole on Long's Peak before the afternoon storms come in/ On Everest, can we make it to the Hillary Step before 1:00 PM? No? Turn back, you're gonna die if you continue.
Can we make it to the delivery date at the pace we're on now, AND with the emerging situation for the remaining work, AND for the cost we're trying to keep AND with the needed capabilities the customer needs? Remember the use of past performance is fine, If and Only If the future is something like the past, or we know something about how the future is different from the past.
When the future not like the past? We need a Plan B. And that plan has to have estimates of our future capabilities, cost expenditure rate, and our abilities to produce the needed capabilities.
ALL PLANNING IN THE PRESENCE OF UNCERTAINTY REQUIRES - MANDATES ACTUALLY - ESTIMATING.
Ask any hiker, climber, development manager, business person. Time to stop managing by platitudes and start managing by the principles of good management.
The Art of Systems Architecting† is a book that changed the way I look at development of software intensive systems. As a manager of software in the system of systems domain, this book created a clear and concise vision of how to assemble all the pieces of the system into a single cohesive framework.
One of the 12 principles of the Agile Manifesto is The best architectures, requirements, and designs emerge from self-organizing teams. The self-organizing team parts is certainly good. But good architectures don't emerge, unless it's the Ball of Mud architecture. Good architecture is a combination of science, engineering and art. Hence the title of the book.
Systems architecting borrows from other architectures, but the basic attributes are the same: †
- The architect is principally the agent of the client, not the builder. The architect must act in the best interests of the client.
- The architect works jointly with the client and the builder on the problem and the definition of the solution. Systems requirements - in the form of needed capabilities, their Measures of Effectiveness, Measures of Performance (MOP), Key Performance Parameters (KPP), and Technical Performance Measures (TPM), are an input. The client will provide the requirements, but the architect is expected to jointly help the client determine the requirements.
- The architect's product is an architectural representation. A set of abstracted designs of the system.
- The product of the architect is not just a physical representation of the system. Cost estimates are part of any feasible deliverables as well. Knowing the value of some built item requires we also know the cost. The system architecture must cover physical structure, system behavior, cost, performance, delivery schedule, and other elements needed to clarify the clients priorities.
- The initial architecture is a Vision of the future outcome of the work effort. This description os a set of specific models. These include the needed capabilities, the motives of the outcome, beliefs, and unstated assumptions. These distinctions are critical when creating standards for the architecture. ToGAF and DoDAF are examples of architecture standards.
Why Do We Care About This?
When we hear of some new and possibly different approach to anything, we need to ask - what is the paradigm this idea fits into? If it is truly new, what paradigm does it replace and how does that replacement maintain the needed information from the old paradigm used for success and what parts of the old paradigm are replaced for the better and how can we be assured that it is actually better?
One answer starts with the architecture of the paradigm. In the case of managing projects this is the programmatic architecture. This Principles, Practices, and Processes of the Programmatic Architecture.
Five Immutable Principles of project success can be found in...
With these principles we can apply Five Practices guided by these Principles
With the Principles and Practices in place, Processes can be defined for the specific needs of the domain.
So with the Principles, Practices, and Processes in place, we can now ask
When it is suggested a new approach be taken, where does that approach fit in the Principles, Practices, and Processes that are in place now? If there is no place, how does this new suggestion fulfill the needs of the business that are in place? If there needs aren't fulfilled, does the business acknowledge that those needs are no longer needed?
If not, the chances of this new idea of actually being accepted by the business are slim to none.
There are several paradigms for Systems Thinking. Ranging from Psychobabble to hard core Systems Engineering. A group of colleagues are starting a book with a working title Increasing The Probability of Project Success, several of the chapters are based on Systems Thinking.
But first some background between Systems Theory, Systems Thinking, and Systems Engineering
Systems Theory is the interdisciplinary study of systems in general, with the goal of elucidating principles that can be applied to all types of systems at all nesting levels in all fields of research.Systems Engineering is an interdisciplinary field of engineering that focuses on how to design and manage complex engineering systems over their life cycles.
Systems Management (MSSM, USC, 1980) is an umbrella discipline encompassing systems engineering, managerial finance, contract management, program management, human factors, operations research, in limitary, defense, space, and other complex systems disciplines)
Here's are two books references that inform our thought processes
This book is the basis of Thinking about systems. It's a manufacturing and Industrial Engineering paradigm. Software Intensive Systems fit in here as well, since interfaces between system components define the complexity aspects of all system of systems.
This book opens with an Einstein quote In the brain, thinking is doing. As engineers - yes software engineering is alive and well in many domains, no matter how much we think wqe have to do. We can plan, prepare, and predict, but action occurs through doing.
so when we hear any suggestion, ask how can this be put to work in some measurable way to assess the effectiveness and performance of the outcomes?
This is the companion mapping processes book. Systems Thinking is the process of understanding how systems influence one another withn a world of systems and has been defined as an approach to problem solving by viewing our "problems" as parts of an obverall system, rather than reacting to a specific part or outcome.
There are many kinds of systems. Hard systems, software systems, evolutionary systems. It is popular to mix these, but that creates confusion and removes the ability to connect concepts with actionable outcomes.
Cynefin is one of those popular approaches that has no units of measure of complex, complicated, chaotic, and obvious. Just soft self referencing words.
so in our engineering paradigm this approach is not very useful.
Along with these appoaches are some other seminal works
- The Art of Systems Architecting, 2nd Edition, Mark Maier and Eberhardt Rechtin
- Systems Engineering: Coping with Complexity, Richard Stevens, et al
- Systematics: How Systems Work and Especially How They Fail, John Gall
- The Systems Bible: The Beginner's Guide to Systems Large and Small, John Gall
In The End
Everything's system. Interactions between components is where the action is and where the problems come from. Any non-trivial systems has interactions that must be managed as system interactions. this means modeling these interactions, estimating the impacts of these interactions. defining the behaviors of these interaction before, during, and after their development,
This means recognizing the criteria for a mature and effective method of managing in the presence of uncertainty.
- Recognition by clients and providers the need to architect the system.
- Acceptance of a disciple to those function using known methods.
- Recognition of the separation of value judgements and technical decisions between cleint, architect and builder.
- Recognition that the architecture is an art as well as a science, in particular, the development and use of nonanalytical techniques.
- Effective utilization of an educated professional staff engaged in the process of systems level architecting.
This month’s free project management template is a decision log. Decisions are taken in all kinds of settings: meetings, on email, when you bump into someone in the corridor… From experience I know that it’s a) hard to remember what decision you took, and b) difficult to find information hidden in meeting minutes to remind yourself of why that decision was taken.
This template sorts out both those problems. Once you’ve started using it you won’t look back, promise!
It would also be great for recording decisions for charity and community projects.
Download the decision log template by hitting the button below. Downloading will also subscribe you to my newsletter – unsubscribe if you don’t want to receive it, although that would be a shame because it’s AWESOME.
This free project management template is yours to use however you like. Add sections, delete sections – do what you want with it. But don’t sell it on. Thanks!
If you have any problems with the download then get in touch via the contact me form and I’ll sort you right out.
One of the first things that project managers learn on training courses is that a project has a start, a middle and an end. Unfortunately, outside the classroom you’ll come across projects that don’t work like that.
A zombie project is one that never ends. It simply consumes resources and carries on because no one has the foresight (or courage) to kill it off.
Spotting the zombie project
Projects and operational work coexist on large programmes so it is quite likely that at some point in your project management career you will be asked to get involved with operational work. And it may feel like your project is never-ending. However, zombie projects are not operational, day-to-day work. They are projects that:
- lack structure
- have poor management
- have poor oversight; and
- lack of governance.
Like the zombies in films, they are mindless. The project managers and the teams leading them don’t ask the basic question – why? Why should we do it like this? Why are we doing this project at all? If these projects can’t be rescued and turned into something useful, they should be closed down. After all, they are sucking up valuable resources that could be put to better use working on something else.
Killing those zombies — a case study
So you’ve found yourself on a zombie project? Take heart, you aren’t the only one. “I used to have a position as an advisor to a U.S. Government PMO,” says Derek Huether, an enterprise Agile coach and trainer. “It was a traditional PMO, filled with certified professionals doing very good work in very specific areas of expertise. We had budget specialists, schedule specialists, earned value specialists, and even contract specialists. The projects being managed were very traditional in nature, with the exception of one thing. They never ended!”
He might have been able to forgive the long timescales if this PMO was managing projects committed to the construction of battleships or the next generation of an interstate highway system. “I realise these would take years to plan and implement,” he says. “But this PMO was managing software applications, both in development and in operation. So, why is it these projects never ended and never seemed to deliver anything of value? Why is it they just wouldn’t die? It is because, of course, these were zombie projects.”
Faced with a set of projects that were simply taking up space, Derek had to make a choice. “I would like to say I killed off all of these zombie projects or at least put them all back on course to delivering value to the taxpayers,” he says. “Alas, if you are a connoisseur of zombie movies like I am, you know there is only one thing you can do. Divide and conquer.”
How to get that zombie project finished
Derek identified one small project that he knew a small team could bring back from the brink. “We identified what deliverables were most important to the project sponsor,” he says. “Then we established a small cross-functional team, asking some members to work outside of their functional expertise, to allow the flow of work to be regulated.”
Derek took an Agile approach, scheduling a daily 15 minute standing meeting to communicate status and deal with issues and risks. “We asked the team to demonstrate to the project sponsor what they had got done in the previous week, to allow the sponsor to accept or reject what was done and provide feedback and insights into shifting priorities,” he says.
Derek and his team established regular weekly deliveries of product, to build onto previously delivered items, and they clearly identified a project end date. “Whatever we had done by that date would be it, without new project sponsorship and the creation of a new project following the same parameters of our new non-zombie project,” he says. As a result, he brought this particular zombie project back under control and ensured it delivered something of value to the project sponsor.
You can do the same: don’t let your project turn into a zombie project taking up resources and energy that could be better used elsewhere. You might not be able to stop it, but at the very least recognise when it has happened and recommend that the project is closed down. Otherwise you’ll be mindlessly supporting a project that is going nowhere and has nothing to offer. Cut your losses and run!
A version of this post first appeared on the BCS website.
There are three mistakes you might be making every day at work. Whether you are managing small projects or a team of global experts, I’ve seen managers of all grades make these errors time and time again. And I’ve done it too.
Susanne Madsen writes about the three mistakes that managers make in her book, The Power of Project Leadership. I’ve taken her headlines and added what I think they mean for managers today. Do you recognise these traits?
Mistake #1: Managing tasks and events
Managing tasks and events? That’s your job, so how can it be a mistake?
The management error comes when you focus on managing tasks at the expense of leading people.
People get work done. Teams deliver projects. Step away from the tasks and look at the bigger picture. It’s no good having the most detailed task plan if your team are bored or stressed. Managing people should take up most of your time.
In my experience people who are good at managing projects and tasks are less good at managing people. Perhaps because they don’t enjoy it as much as tweaking a project schedule. Perhaps because they don’t think it is as important. People have always been important but it’s even more acute now. Unhappy team members leave. Or worse, they stay and are disruptive and share their bad mood with everyone else.
Fix it by mentally allocating time in the day to leadership tasks like:
- Meeting people in person
- Checking in with people on the phone
- Setting goals
- Clarifying the vision and objectives for your projects (over and over again).
To move to this way of thinking we have to ditch the view that leadership and management are different. OK, they are different, but you can’t compartmentalise them in real life. They are only different when you’re reading or studying about them. In my day-to-day work I don’t ‘switch’ between being a leader and being a manager. I do them both. All the time. Whether I’m leading or managing is not a conscious choice, it’s a function of my job.
Mistake #2: Being reactive
I’m reactive. I deal with emails as they come in. It can be quite a stressful way to work. I’d love to have more time to be proactive but hey, it takes time to get organised enough to be proactive and time is something I don’t have much of.
And I know that attitude is wrong.
When we focus on what’s urgent we stop focusing on what’s important. Urgent things take up brain power that would be better used on other tasks such as getting ahead for next week or planning for that project meeting.
You can be proactive. You can look at what might stop you achieving your goals, deal with those risks and look forward at supporting your team. Strategic planning cycles force us to do this, but you probably only bother to go into the details of that once a year, or when a new project needs to be prioritised against the existing portfolio.
Think now about the one thing you could do to deal proactively with something you know is going to happen on one of your projects. That could be:
- Reviewing your plans and updating them
- Putting your risk management plans into action
- Contacting your stakeholders to let them know what’s coming up
- Preparing a communications plan
- Organising a team celebration for when the project is over.
Or anything else that makes you feel calm and collected inside (that doesn’t include wine and chocolate).
Related: How To Prepare For Next Week
Mistake #3: Believing that we have to know it all
I know a lot of things. For example, I knew that envelope neck baby gros are designed to be taken off downwards as well as over the head before that revelation did the rounds on the internet a while ago. But I didn’t know how to fold a nappy in on itself when you throw it away before another mother showed me.
I don’t do either of those things at work, but the point is that you can’t know it all. As a parent or as a manager. There isn’t enough space in your head for everything. Besides, we have the internet and our colleagues and books for the things we don’t know.
The important thing is to know where you can go for the information. Then you have access to knowing it all.
Stop trying to prove that you know how to fix problems and do all the tasks. Use your experts to fill the gaps in your knowledge and accept that they know how to do it far better than you ever will.
These three mistakes can be career-limiting. People with good interpersonal and leadership skills get promoted. Good project and task managers stay doing what they are good at (and if that’s what you want to do in life, then that’s fine – we need managers like you too!). Start shifting the way you relate to your team and ditch these unproductive habits.
I’m delighted to announce the winners of our Project Management Fast Track training course in conjunction with Activia Training.
We selected two worthy winners from the eligible entries. Here they are:
Tine from Norway wrote:
I’d benefit from attending the Project Management Fast Track course because I am still new to project management, and I had some project management in college, but that is 6-7 years ago.
I am the only PM in my small Norwegian office, and the other PM’s are placed in Stockholm, Copenhagen and Paris. Since we are not sharing a space, it is much more difficult to get the exchange of knowledge and practices the others use. Since I have no former experience, I find this extra challenging.
As we are a relatively newly formed company (result of a merger) and PM’s, as I understand it, were not really organized until right before I started here. This means we do not have any kind of particular PM method we follow either, so everyone just does what they are used to. Which leaves me in a bit of trouble, as I have not really done a lot before, but I do feel like using best practices.
I would get updated, relevant knowledge and best practices.
Yes, Tine, you would! I hope you enjoy travelling to London to take your course later this summer.
Sophie from the UK wrote:
I’d benefit from attending the Project Management Fast Track course because I undertook some training a few years ago but have struggled to find a role in which I can use it, due to lack of experience.I feel that this course would help show a commitment to working in Project Management. I also feel that the practical information offered in this course (e.g. about project management tools) will be of big help to me as I feel those would provide me with a good grounding of usable tools rather than only the broader concepts, which I find harder to translate into usable day-to-day plans.
Absolutely! Broad concepts are good to know, but they don’t help you put plans into action on Day 1. This course will definitely help you do that, so I hope feel that you get a lot out of it when you attend your session this summer.
Thanks very much to the team at Activia Training for sponsoring this giveaway and well done Tine and Sophie.
The latest giveaway on A Girl’s Guide to Project Management is to win a copy of Jeff Furman’s book, The Project Management Answer Book. Find out how to enter that giveaway here.
Simply get in touch via the contact form with the phrase: “I know all the answers!” and I’ll enter you into the draw.
The giveaway closes at close of business UK time on Friday 19 June 2015.
If you can’t wait to find out if you have won, you can:
- Read my interview with Jeff about how he updated the book and why he added a new chunk on stakeholder management.
- Buy The Project Management Answer Book on Amazon*
Don’t delay, enter here today!
Normal giveaway rules apply – read them here.
* This article contains affiliate links at no cost to you.
One practice is to start the day with meditation, not checking any electronic devices. I'll admit, sometimes when I'm working from home I'll turn on the TV while making my morning coffee before heading up to the office, but I don't start responding to email first thing in the morning.
Another recommendation is to journal. Your mind is the most sharp in the morning so that is not the time to waste responding to emails. Instead figure out what your top two or three priorities are and try to get those accomplished first thing in the morning. Journaling can help you figure out where to start your day.
I have also found that I can change my evening routine to be more productive as well. I find when I'm traveling and staying at a hotel, that if I skip the TV and put on music instead, that I'm more focused and get more work done.
So is it time to change up some of your routines?
This is a guest post by Frances Place.
After years working on project teams, there’s no doubt in my mind that a shared understanding and clear vision for the scope of a project, at the outset, is crucial.
I’ve worked on many projects with teams dutifully following lists of fixed requirements, only to discover we’re going off in different directions because we’ve misunderstood the vision, or we’ve missed a detail because the requirements aren’t exact enough.
Finding a technique that explains scope in the context of the vision is hard.
Traditional project specifications do the job of detailing the scope, but they don’t show how it all fits together. These requirements lists focus on what will be done and when, but not what it means for the user.
To fully understand the context of the project, and the user’s point of view, the project team and stakeholders need additional briefing time, which often eats into precious delivery time.
And the specifications are fixed. There is no flexibility to change as the project progresses.
But what if there was a more dynamic way to capture changing requirements in the context of the vision, that would brief and engage the whole team in the process?
User story mapping: a simple way to scope projects
Agile consultant Jeff Patton was tackling the same issues. He needed to turn a list of requirements into something meaningful that communicates the vision and shows the project priorities.
So he created user story mapping: a visual way to outline, sort, and prioritise what you need to do.
The user story map shows the whole scope of the project in one place and is created through a collaborative process involving the development team, the product owner and any other interested stakeholders.
This diagram shows the structure of a finished map. Patton’s book User Story Mapping* gives detailed advice on how to use the technique for better project scoping, but in brief:
- Begin by detailing the tasks a user is aiming to achieve with the product, then group these into activities (high level goals) to form the backbone of the map.
- Have everyone in the team work together to add user stories as sticky notes underneath each task. These add the detail of what needs to be delivered.
- Involve the whole team in prioritising the user stories into versions which become the basis for the project plan.
The benefits of user story mapping
I have been using this technique for over a year and I now can’t start a project without it – it is an invaluable tool for us for a four reasons:
1. Seeing the product visually mapped out is powerful
As the features are told through a story, on the wall in front of you, you can spot gaps and errors in your thinking before you begin to build the product.
For example, here you can spot whether you have captured stories for updating the user’s profile but forgotten to add a requirement to create the profile in the first place. Errors like this are easy to spot when you tell the user’s story.
2. Prioritisation becomes meaningful
There’s something very different about the physical act of moving a sticky note above or below a release line from the virtual act of changing the priority level of a feature in a spreadsheet or online tool. It feels more real.
Whilst it is the Product Owner who owns the prioritisation, the whole team sees the decision making. Anyone can challenge the choices made, allowing the whole team to push each other to build the least possible at each stage, getting the product into the user’s hands quicker.
3. It allows you to adapt as you learn
The map is intended to be a living artifact that can be posted on your office wall, reminding everyone of the bigger picture of the product.
It can be used to continually review the backlog, adapting it as you learn more about your users.
4. It is a tool for shared understanding
Perhaps the biggest, and most hidden, benefit is that of engagement. Having the whole team, including the product owner, together for a user story mapping session is by far the most efficient way of getting everyone to understand the product, and each other. They are all part of shaping it, and become a stronger team in the process.
And, because everyone has contributed ideas to the map, they get a sense of ownership and are more invested in the project than they would be after a more traditional briefing.
So give it a try for your next project. You might find you’ll get feedback like I did from a client I introduced to user story mapping.
He’d been working on a project for over 18 months and had a clear vision in his head that he needed the whole team to capture and understand. When he saw the map he said:
“For the first time I can see the shape of the whole product in front of me.”
For him, his vision was finally becoming real.
* This article contains affiliate links at no cost to you.
There are several BS detector paradigms. One of my favorites is Carl Sagan's. This one has been adapted from Reality Charting the book that goes along with the Apollo Method Root Cause Analysis process we use in our governance process in our domain. Any outage, any hard break, and disruption to the weekly release process is cause for Root Cause Analysis.
Here's Carl's check list applied to the #NoEstimates conjecture that decisions can be made in the absence of estimates
- Seek independent facts.Remember, a fact is a cause supported by sensed evidence and should be independently verified by you before it can be deemed legitimate. If you cannot find sensed evidence of causal relationships you should be skeptical.
- Writing software for money is based on making decisions in the presence of uncertainty.
- a primary process for making those those decisions is Microeconomics and Opportunity costs. What's the lost opportunity for one decison over another?
- To do this we need to estimate both the cost that results from choosing one decision over another and the benefits, opportunity, from that decision.
- Welcome open debate on all points of view.Suspend judgment about the event or claim until all cause paths have been pursued to your satisfaction using RealityCharting®.
- The notion that #NoEstimates is exploring and seeking conversation is not evidenced.
- Any challenge questions are labeled as trolling, harassing, and unwanted.
- You'd think is #NoEstimates is the next big thing responding to any and all challenges would be a terrific marketing opportunity. It's basic sales strategy, find all objections to your products vale propositon, over come them, and the deal is closed.
- Always challenge authority.Ask to be educated. Ask the expert how they came to know what they know. If they cannot explain it to your satisfaction using evidence-based causal relationships then be very skeptical.
- This is not the same as challenge everything.
- This is when you hear something that is not backed b tangible evidence challenge it.
- Ask the person making the claim how they know it will work outside their personal anecdotal experience?
- Consider more than one hypothesis.The difference between a genius and a normal person is that when asked to solve a problem the genius doesn’t look for the right answer, he or she looks for how many possible solutions he or she can find. A genius fundamentally understands that there is always another possibility, limited by our fundamental ignorance of what is really happening.
- The self proclaimed thought leaders, agile leaders were challenged, I've been challenged, I must be a agile though leader, needs to be tested with actual evidence.
- Don’t defend a position because it is yours.All ideas are prototypical because there is no way we can really know all the causes. Seek to understand before seeking to be understood.
- Use this on both sides of the conversation.
- Where can non estimates be applied?
- Where is it not applicable
- Provide evidence on both sides.
- Try to quantify what you think you know.Can you put numbers to it?
- Show the numbers
- Do the math
- If there is a chain of causes presented, every link must work. Use RealityCharting® to verify that the chain of causes meets the advanced logic checks defined above and that the causes are sufficient in and of themselves.
- If estimating is the smell of dysfunction, show the causal chain of the dysfunction.
- Confirm that estimating is actually the root cause of management dysfunction.
- Is misuse and abuse of estimates caused by the estimating process?
- When conjecturing that stopping estimates fixed the dysfunction, is this the simplist solution?
- How about stopping Bad Management practices
- In the upcoming #NoEstimates book, Chapter 1 opens with a blatant Bad Management process of assigning a project to an inexperienced PM that is 100's of times bigger than she has ever seen.
- Then blaming the estimating process for her failure.
- This notion is continued on with references to other failed projects, without ever seeking the actual root cause of the failure.
- No evidence is ever presented to show that stopping estimates will have make the project successful.
Try to prove your hypothesis wrong.Every truth is prototypical and the purpose of science is to disprove that which we think we know.
- This notion is lost on those conjecturing #NoEstimates is applicable their personal anecdotal experience.
- Testing the idea in external domain, not finding a CEO that supports the notion.
- The null hypothesis test H0, is basic High School statistics.
- Missing entirely there
Use carefully designed experiments to test all hypotheses.
- No such thing in the #NoEstimates paradigm
So it's becoming clear #NoEstimates does pass the smell test of the basic BS meter
The Big Questions
- What's the answer to how can we make a decision in the presence of uncertainty and not estimate and NOT violate the core principles of Microeconomics
- It's not about the developers like or dislike of estimates. When I was a developer - radar, realtime controls, flight avionics, enterprise IT - I never liked estimates. It's about business. It's not our money. This notion appears to be completely lost. It's the millennials view of the world. We have two millennials (25 and 26) It's all about ME. Even if those suggesting are millennials, the message appears to be it's all about me. Go talk to the CFO.
The rhetoric on #NoEstimates has now reached a fever pitch, paid conferences, books, blatant misrepresentations. Time to call BS and move on. This is the last post. I've met many interesting people in both good and bad ways. And will stay in touch. So long and thanks for the Fish. As Douglas Adams says. Those with the money will have the final say on this idea.
There’s only one thing worse than being told bad news, and that is being told about bad news late. When a programme is failing, you should define the problem and potential solutions, and alert stakeholders at the first sign of trouble, according to LeRoy Ward, Executive VP at ESI.
His ‘Managing and Saving Programmes in a Changing World’ webinar covers 5 steps for project recovery.
Ward started off by explaining what a ‘troubled programme’ is. There are several things that can go wrong in programme management:
- Business case deterioration: the programme started off with a good business case but it no longer stacks up.
- Stakeholder evolution: people change and new leaders at the top change the direction of the programme.
- Technical failure: this creates a programme integration risk as what you are building might not sit in the organisation’s architecture any longer.
- Resource collapse: either in the form of strikes or a key resource leaving.
Focus on gaining control
Don’t focus on the wrong issue. The wrong issue is how you can catch up and finish on time. The right issue is how do you finish at all and gain something realistic benefit without ending up with a failed project.
You need to regain control. ‘Control’ is the scope, dates and roles on the programme which have been lost in through planning or execution in the first place. The way out of this is to make big, targeted changes quickly.
This conflicts with the advice Scott Berkun gives in his book Making Things Happen*. He warns that if you make large changes you push the project off course and it can take a while before you see what you have done. Then you over-correct by making another big change and you just weave from one crisis to another because you can’t keep your project on course. So be careful about making big changes on a project that isn’t going that far wrong.
Problems facing failing programmes
Ward identified several problems faced by failing programmes:
- Completing an accurate assessment of programme problems is difficult for the programme management team because they lack objectivity. Using an outside assessment team creates objectivity. Bring in technical specialists as required.
- There will be pressure from stakeholders to commit to a new schedule. Measuring progress in small steps will help tremendously.
- It takes time to determine the work remaining. Data about how far off the original estimates were is needed to make accurate forecasts.
- You need to sustain progress while planning recovery. Additional temporary resources will be needed to do this. The programme manager should direct the current workflow plus do all the work required to make progress with the recovery – no easy task!
Ward cautioned against declaring victory too soon. Sustained control is necessary to prove that something has been turned around. It takes teamwork to turn a programme around and then keep it moving in the right direction.
If you seeing any of the problems faced by troubled programmes then you need a project recovery plan to get back on track.
The five-step project recovery plan
The wrong issue is how you can finish on time. The right issue is how do you finish at all.
Step 1: Define Charter
Duration: 1-2 days
This formally sanctions the existence of an assessment and project recovery effort. It provides the assessment and recovery lead with the proper authority to complete the activities necessary to develop an assessment plan.
Define the charter with the sponsor and steering committee. The charter should cover:
- Programme history and sensitivities (although I wouldn’t write all this down)
- Assessment approach: how many people are you going to interview, in individual meetings or in group sessions and so on.
- An action plan with dates.
Then get it all agreed – which is what the charter is for. In this step you would also initiate contact with the programme and project teams.
Step 2: Develop assessment plan
Produce your plan for assessing what is going on in the troubled programme. Aim to allow the assessment team to perform their assessment quickly, ensure accurate findings, and minimise distractions for the project team. After all, you want to keep going with things that are progressing well.
During this time you will:
- Establish a team
- Review and analyse the assessment model (how are we going to review documents, how are we going to move forward with analysis)
- Review critical documents
- Develop assessment plan.
This is a formal step, so get the recovery plan signed off.
Step 3: Conduct assessment plan
Duration: 2-5 days
Carry out the activities on your plan. Determine the true current status of the programme and constituent projects. Look for major threats, opportunities and problems. You begin to consider the recovery as well as who would be on your recovery team.
The work required at this step includes:
- Establishing a war room
- Assembling the team
- Implementing the assessment plan (interviews and document review)
- Aggregating and ranking the findings from the most problematic to least problematic
- Validating, updating and finalising your findings with the programme team and sponsor.
Step 4: Develop recovery plan
This step leads to a plan to get to a functioning programme. You establish a road map and process to achieve the goals, and continue to build confidence and morale.
Prepare a plan that everyone sees as realistic and achievable: this helps build confidence. There is no Plan B for this recovery plan: this is it! The goal is to save the programme from loss and restore it to usefulness, preventing total failure along the way.
- Produce an achievable schedule
- Re-establish customer management confidence
- Negotiate a new baseline
Step 5: Conduct recovery plan
Now execute your recovery plan to get the programme back on track or at least delivering something valuable. This includes validating all the estimates and checking how people arrived at them because it helps you produce an accurate forecast for programme completion.
Through all of this what you are trying to do is begin with the end in mind: a programme that is no longer in recovery. If you keep that objective at the heart of everything you do you’ll get to a successful conclusion. That might be:
- A project or programme that is shut down
- A project or programme that is back on track
- A project or programme that isn’t going to deliver everything the sponsor hoped for but will turn in something of value.
Any of those options are OK because the uncertainty has gone.
If you’ve read this far, click through to my definitive guide to project success criteria next. It gives you a breakdown of how to define success which might help you avoid a failing project in the first place.
* This article contains affiliate links at no cost to you.
The current misrepresentation approach is to quote people like Bent Flyvbjerg - who by the way does superior work in the domain of mass transportation and public work. Bent, along with many others, one of which is a client, have studied the problems with Mega Projects. The classic misuse of these studies starts with the reading of the introduction of a report and going no further. Here's a typical summary.
9/10 Costs (are) underestimated. 9/10 Benefits (are) overestimated 9/10 Schedules (are) underestimated.
OK, we all know that's what the report says, now what?
- Do you have a root cause for each of the project's overages?
- Did those root causes have sufficient assessment to show:
Primary Effect – is any effect we want to prevent.
Action – momentary causes that bring condition together to cause an effect.
Conditions – the fundamental causal element of all that happens. It is made up of an effect and its immediate causes that represent a single causal relationship.
- As a minimum, the causes in this set consist of an action and one or more conditions.
- Causal sets, like causes, cannot exist alone.
- They are part of a continuum of causes with no beginning or end, which leads to the next principle that Causes and Effects are Part of an Infinite Continuum of Causes.
NO?, then the use of reports and broad unqualified clips from reports is just Lying With Statistics.
The classic example from the same source states Steve McConnell PROVES estimates can't be done in his book. Which of course the antithesis of the title of the book and the content of the book.
This approach is pervasive in places where doing your homework appears to be a step that was skipped.
From our own research in DOD ACAT1 programs (>$5B qualifies for Megaprojects) here's the Root Cause of program problems in our domain.
When we hear some extracted statement from a source in another domain - Bent for example is large construction infrastructure projects - roads, rail, ports - moved to our domain without the underlying details of both the data, the root causes and all the possible corrective actions to avoid the problem in the first place - that idea is basically bogus. Don't listen. Do your own investigation, learn how to not succumb to those who Lie With Statistics.
So let's look at some simple questions when we hear there are problems with our projects or projects in other domains trying to convince us it's applicable to our domain.
- Was there a credible set of requirements that were understood by those initiating the project?
- No? You're going to be over budget, late, and the products not likely to meet the needs of those paying.
- No? Then what ever estimate was produced is not going to be what the project actually costs, its duration, or the planned value.
- No? Then those uncertainties are still there and will cause the project to be over budget and late.
- If the reducible risks are unaddressed, will come true with their probabilistic outcomes will drive the project over budget, late, and not provide the needed capabilities
- If the irreducible risks don't have margin, you're late and over budget before you even start.
- No? Then money will be spent and time will pass and there is no way to know if the project is actually producing value and meeting its goals.
These questions and their lack of answers are at the heart of most project performance problems. So pointing out all the problems is very easy. Providing corrective actions once the root cause is discovered is harder, mandatorily harder by the way. Because Risk Management is How Adults Manage Projects.
First let's look at what Bent says
He states the political economy of megaprojects, that is massive investments of a billion dollars or more in infrastructure or technology, consistently ends up costing more with smaller benefits than projected and almost always end up with costs that exceed the benefits.
So the first question is are we working in the mega project domain? No? Then can we assert Bent's assessments are applicable. If we haven't then we're Lying with Statistics. (Read Huff's book to find out why).
Flyvbjerg then explores the reasons for the poor predictions and poor performance of giant investment projects and what might be done to improve their effectiveness. Have we explored the reasons why our projects overrun? No? Then we haven't done our homework and are speculating on false data. Another How to Lie With Statistics.
Stating that projects over run 9 out of 10 times without also finding the reasons for this is the perfect How to Lie with Statistics. Make a statement, no supporting data, be the provocateur.
When we read a statement without a domain or context, without a corrective action, that is intended to convey a different message, taken out of context, without the evidence it is applicable in our domain, than the person writing the original statement, is Lying with Statistics - don't listen, go find out for yourself.
When we hear all the difficulties, misuse, abuse, and inabilities for making software development estimates, the real question is what does the business think of this?
Good question. When our children were young - 6 or 7 - they asked the big question once they started receiving an allowance for household chores.
What's the reason we have money? The best answer I could think of was money provides the vehcile for the exchange of value. I pay you for doing something around the house which is of value to me or your mother. That money you receive can then be used to buy something of value for you. You can exchange your money for that valued thing.
Money is the carrier of value between two parties in the transaction.
The basis of a successful business is the exchange of cost (money) for value. Either internally for building a product or externally for providing a service to an outside firm.
In practice this value and the cost to achieve this value operate in the presence of uncertainty in non-trivial situations. If I see a bicycle helmet I want, (notice I didn't say need, since I have a perfectly good and nice helmet) I can look at the price tag and determine if my old helmet needs to be replaced. That is is the value of the new helmet of sufficient value to me that I'm willing to pay the cost and absorb the cost of the old helmet?
The price tag for the Helmet is clear. I might be able to get a discount. The value of the helmet is up to me. As a minimum the value is equal to the cost. This is the basis of Earned Value Management. But the value of the helmet may be immeasurable if it saves my from a brain trauma if I were to crash. I've never crashed or been hit on my road bike. A few small spills on the mountain bike.
The Business Notion of Value in Exchange for Cost
In the business of software development the exchange process takes place in the presence of uncertainty, there are no price tags attached to the development process in the way the helmet does. Uncertainty about the value - beyond the cost. Uncertainty about the cost. Uncertainty about the risks, and all the other random variables associated with the project work.
When making decisions in the presence of these uncertainties, we can consider the opportunity cost. This is the loss of potential gain from other alternatives when one alternative is chosen. If i choose one path for one cost over another path of another cost, what's the lost opportunity? This decision making process is the basis of Microeconomics as it is applied to Software Development.
Opportunity costs are fundamental costs in economics, and are used in computing cost benefit analysis of a project. Such costs, however, are not recorded in the account books but are recognized in decision making by computing the cash outlays and their resulting profit or loss.
So let's ask a simple question...
How can we make those opportunity cost decisions in the presence of the uncertainty of their specific value? Meaning of the "value" of the Value - an actual number of Dead Presidents (dollars) is a random variable, dependent on a variety of things - can we make a decision in the presence of this uncertainty? This uncertainty is around the precision and accuracy of our knowledge of this "value."
The answer is we need to estimate the value of the number of Dead Presidents for both the cost of the value and the value of the value. Both sides of the equation are needed. This means we need to know something about the value returned in exchange for our cost to acquire that value. A common - and simple - way to measure that is through the Return on Investment (ROI). This investment in this case is the cost we've assigned to the expected value to be returned. The formula is
ROI = (Value - Cost) / Cost
The two variables in most instances are random variables. If we're Investing in a new helmet like a really nice Specialized S-works, we can make the trade offs - the opportunity costs, between the $250.00 for the helmet and the potential immeasurable value of saving my head on the mountain bike, while riding with our collegiate racer son. The current helmet will likely do that job as well, but that carbon fiber S-works helmet will look very cool while riding next to our sons S-works Epic 29ér. See you can buy cool.
But now we need to determine the opportunity cost for a software system, a feature in a software system, or something else related to a software system. That is we need to decide in the presence of the uncertainty created by the randomness of the many variables of the software process.
How can we do that? Well, and here's the punch line...
WE NEED TO ESTIMATE.
Can we make that decision in the absence of making an estimate? Sure we can guess, we can make a blind decision, we can just decide and suffer the consequences of that decision. But here's the rub as Willy Shakespeare once had Hamlet say, is that if it's not our money we're exchanging for the produced or acquired value, those providing the money have a vested interest in knowing how much money. And when the Value produced or acquired for the money will be returned.
This is the basis of Microeconomics which is defined as the behavior of individuals and small impacting organizations in making decisions on the allocation of limited resources.
So when someone says we can make decisions without estimates, their wrong. Unless hey haveno concern for the loss resulting from the write off of the opportunity cost. It is doubtful that those paying for the value have much interest in that.
Can we make decisions without an estimate of the outcomes? Not in any credible way I know of. If there is a credible way, it has yet to be stated. Slicing is estimating. Using past performance for forecasting (estimating outcomes in the future) is estimating.
So the simple answer to the conjecture of making decisions in presence of uncertainty in the absence of an estimate is also simple
And anyone saying they can needs to come to grips with the principles of microeconomics of software development.
A Girl’s Guide to Project Management is 10 next year so I’ve been thinking about what I would like to do to celebrate. While I was musing, Viktoria from Bitrix24 got in touch to tell me about her anniversary.
Bitrix24 is a free unified collaboration platform and they turned three years old in April. When they launched the service in 2012, they did not anticipate that they would be adding over 1500 new companies every day, as they do now, she explained. This came with the inevitable growing pains, but now they have clients in 225 countries and territories (which is a few more than this blog: I can only claim 164 countries).
Not bad for a tool I had never heard of. Viktoria explained that the rapid growth of the platform can be attributed to the frequency of new features. Bitrix24 undergoes several major updates a year, and the most recent one adds many improvements to frequently used tools.
Bitrix24 now gives users the ability to work with documents stored in popular cloud storage services, such as Dropbox, OneDrive and Google Drive. Task templates have been improved and now allow checklists and subtasks. Video conferencing now supports HD format as well as the ability to share screens in one-on-one conversations.
The collaboration platform comes with built-in CRM and telephony, and Viktoria says that the company’s statistics show that more than 42,000 phone calls are made via Bitrix24 daily.
How are we celebrating this anniversary? Sign up for a free account at the Bitrix website and use the promo code PM4GIRLS to claim an extra 5Gb of drive space. This code is valid until 15 June 2015.
As for my anniversary next year, I’m still thinking. Any suggestions?
When I use a word Humpty Dumpty said in a rather scornful tone, it means just what I choose to to mean - neither more nor less.
The question is, said Alice, whether you can make words mean so many different things.
The question is said Humpty Dumpty which is to ne master.
Through the Looking Glass, Chapter 6
The mantra of #NoEstimates is that No Estimates is not about Not Estimating. Along with that oxymoron comes
Forecasting is Not Estimating
- Forecasting the future based on past performance is not the same as estimating the future from past performance.
- The Humpty Dumpty logic is Forecasting ≠Estimating.
This of course redefines the standard definition of both terms. Estimating is a rough calculation or judgment of a value, number, quantity, or extent of some outcome.
An estimate is Approximation, prediction, or projection of a quantity based on experience and/or information available at the time, with the recognition that other pertinent facts are unclear or unknown.
- Let’s estimate how many Great Horned Owls are in the county by sampling.
- Let’s estimate to the total cost of this project using reference classes assigned to work element duration and running a Monte Carlo simulation
Forecasting is a prediction of a future event
- Let’s produce weather forecast for the next five days
Both Estimating and Forecasting result in a probabilistic output in the presence of uncertainty
Slicing is Not Estimating??
Slicing work into smaller pieces so that "standard" size can be used to project the work effort and completion time. This is a standard basis of estimate in many domains. So slicing is Not Estimating in the #NoEstimates paradigm. In fact slicing is Estimating, another inversion of the term
No means Yes
Past Performance is #NoEstimates
using Past Performance to estimate future performance is core to all estimating processes. Time series used to estimate possible future outcomes is easily done with AIRMA, 4 lines of R, and some raw data as shown in The Flaw of Averages. But as described there, care is needed to confirm the future is like the past.
When We Redefine Words to Suite Our Needs We're Humpty Dumpty
Lewis Carol's Alice in Wonderland is political allegory of 19th century England. When #NoEstimates redefines established mathematical terms like Forecasting and Estimating and ignores the underlying mathematics for time series forecasting, ARIMA for example, they are willfully ignoring established practices and replacing them with their own untested conjectures.
Key here ways to make decisions with NO ESTIMATES. OK, show how that is not actually an estimating technical, no matter how simple or flawed and estimating technical.