The right question for any suggested improvement, change, or suggesting we stop doing that need to produce an answer to ...
Does this suggestion increase the probability of project success?
This means tracing the suggestion to the outcome of the project being better, faster, cheaper, or some other tangible measure of improvement.
What does project success look like?
The delivery of agreed-upon capability within established resource constriants, e.g. funding, schedule, facilities.
Five factors are used to assess the success
So Now What?
When we hear about something new, anything new, how can we test it that suggestion against business needs, mission needs, governance, or strategy. This starts with establishing the domain in which the suggestion might possibly work. Then proposing the framework in which it has worked or might work. Then a proposed way to assess the possible benefits of performing the sugegsted solution.
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand".
Mary Doria Russell
It is that difference that is needed to assess when a idea passes the smell test.
These participants play off each other, react to emergent streams of melody, contribute their own special talent to the music and pretty much work in a a self directed manner over the course of the performance.
While I'm not a fan of analogies, this is a useful one for the purpose here. There are certainly domains where the Jazz analogy describes what is going on in the trio in the picture to the left.
But what about other music? Music that is just as creative, just as moving, just as impactful to the listener. Beethoven's Ninth Symphony's Ode to Joy with the poem from Friedrich Schiller 1785 work is an example.
Words that have moved nations and populations. Following Beethoven's Ninth was a movie we saw over the weekend that described this result.
In the Ninth, each performer has a score to follow, led by the conductor, but also by the concert master and the senior players in each section. The vocals are also led by a senior performer.
In the software business there are likely similar domains and projects. Ones that can be improvised and ones that require conductors, a concert master, and players who follow the score.
In both cases - and this is where the analogy falls apart - is the players are highly skilled, experienced in the art, having played the basic themes 1,000 of times over before improvising or following the score.
The jazz performance is not made up as it goes. OK, fusion is, but that crap makes my head hurt. Melodies, rules for cords are practiced for 10,000 hours (Gladwell), relationships between the players have magical connections not available to mere mortals. The Jazz Trio and the Berlin Philharmonic are populated with highly skilled and experienced professionals. We've all heard our children play in the school band and know what that sounds like. All the platitudes in the world about agile axioms are of no worth without the necessary capabilities to actually get the work done properly.
Applying the notion that agile software development is like jazz makes as much sense as saying I can sit in the 3rd chair of the trombone section (my high school band position) and play my contribution to Beethoven's Ninth without a Curtis Institute degree in performance and 10 years experience (my aunt was a professional pianist in the late 1950's from Curtis).
It's not gonna happen - in both analogies - without the prerequisites of professional performance capabilities. Otherwise the result sounds like we're back in High School Music class with Mr. Meach (my teacher).
So how long will it take us to be capable performing to a level needed to not smell like we're high school kids in the marching band? I don't know let's make an estimate.Related articles Analogies, the Good, the Bad, and the Ugly The "Real" Root Cause of IT Project Failure
Today’s job search trap is something we can all identify with: biting off a big chunk of work and not getting it to done fast enough. I suspect we have all been there and done that!
How do you avoid this particular trap? I like to assess each of my tasks on my board and ask, “Do any of these look as if they will be more than two hours long?”
Two hours is not a lot of time. Two hours is long enough for me to make progress on something and get it to done. It’s also long enough that I’m likely to complete it. And that’s the key.
You know what the problems are in a job search: you have interruptions, such as phone calls; your family needs you to drive them or do laundry or something else; you want a perfect resume. The list goes on and on.
Instead, think of ways to make your tasks smaller. Here are some approaches:
Tomorrow is the last day of the Manage Your Job Search launch. Yes, I ran the launch Wednesday-Wednesday. That’s one of the tips in Manage Your Job Search, to start your week on a Wednesday. Today is the last conference call about tips and traps. I’ll do a quick intro and answer your questions. Join me?
P.S. I just fixed the title of this post. I misspelled the too, as in too much to do. Oopsie!
There is a continuing discussion in the agile community about delivering value in the order set by the customer. Along with this discussion is the use of the word DONE. A popular phrase is no requirement or piece of software can be considered DONE until it is put to use.
This is a software developers point of view of course. But there is another view of software based products. It starts with the Measures of Effectiveness for the resulting product. These Measures of Effectiveness are:
Operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operation environment, under specific conditions.
This measure of DONE is not directly related to code, testing, requirements or anything like that. It is related to how Effective the software is in delivering the capabilities needed to fulfill the mission or business case.
The individual requirements and pieces of code that implement them can be - or should be - traceable to these capabilities. For each Measure of Effectiveness, we then need a Measure of Performance. These measures characterise:
The functional or physical attributes relating to the system's operation, measured or estimated under specific conditions.
These are also not direclty related to producing code, running tests, or other direct software activities.
All the software design, testing, integration, etc. supports the creation of the ability to produce these Measures of Performance and Effectiveness. For the end user, all the development work is behind the scenes. What the customer actually bought was the ability to do something useful. To put a capability of the software system to work accomplishing a business need. Make money with this capability of course.
So What Does All This Mean?
It means that if you start at the bottom - with the software development processes - you're likley not going to see what the real picture is. This picture is that the customer paid for capabilities, measured in units of effectiveness and performance.
When we start with methods, paradigms, even cockamamie ones like not estimating the cost of the work effort needed to produce the capabilities, we loose the connection to why we are here. We are here to produce software that provides a capability. Likely more than one capability.
So when we hear words like - we can manage projects without knowing the cost or we'll let the requirements emerge, or the customer doesn't really know what they want, so we'll get started so they can decide along the way, ask how you are going to recognize DONE, before running out of time and money?
How Do We Discover the Needed Capabilities?
Once we've decided that capabilities are in fact the place to start, how are they gathered. Here's the top level set of activities.
Once we have these, we can start to elicit the technical and operational requirements that will fullfill these capabilities.
These requirements can be emergent, they can evolve, they can be elicited incrementally and iteratively. But what ever way to appear they need to have a home. They need a reason for being here. They need to enable a capability to be available to the user.
I will be doing a webinar for BrightTALK on Accountability and Engagement, and helping leaders learn how to optimize both, on this Thursday, April 17th, at noon Eastern. It will be just 45 minutes and is free to attend. You can use this link to register.
During this webinar, I will share a model of accountability and engagement and discuss three of the 11 secrets I have outlined in my upcoming book, Double the Love: 11 Secrets to Cultivating Highly Accountable and Engaged Teams. The target audience for this webinar is HR, Training, OD, and Leaders (you!).
And for my HR/Training/OD pals, my webinar is part of a series called the HR Management Summit - check out all the free webinars here.
I hope you can attend the webinar - I just finished the slide deck and I think you will enjoy it and find it insanely useful.
Here’s another job search trap: you think you can network by going to professional group meetings, mashups, informational lunches, and other kinds of what I call “background networking.”
You need to do this kind of networking to expand you network. But it won’t get you a job. It will keep you unemployed.
You need to also create a target list of companies, companies you want to work at. Not types of companies. Real companies, with real names, on a real list. This takes research.
Once you have your target list, you also need to have your marketing spiel (which I describe in Manage Your Job Search), and then you can decide how to find someone at one of your target companies every single week.
If you expand your background networking every week, chances are good you know someone who knows someone at your target company. Maybe you even know someone at your target company! But, if you haven’t defined your target list, you don’t know what you are looking for. It’s a problem.
You do need to go to meetings. You do need to have informational interviews. You need to keep thinking about where you are focusing your networking efforts.
Background networking, by itself, is insufficient. Add target networking to it? Now you have a winning combination.
There are two more days of the Manage Your Job Search launch. I’m hosting conference calls this week. Today’s, April 14, is about networking basics. Tomorrow’s is tips and traps. I’ll do a quick intro and answer your questions. Join me?
Ninety percent of everything is crud - Theodore SturgeonModels ...
When I hear the phrase we're exploring I'm reminded that in fact many who explore without a plan, measures of their progress progress against this plan, a risk management Plan-B for getting home when things go wrong, and without insufficient resources to survive the trip - come home empty handed or many time don't come home at all. Exploring without these items is called wandering around in the wilderness looking for something to eat.
Here's a simple tale about an actual explorer, Ernest Shackleton, who experienced failure and near death on their first expedition to the South Pole (ADM Scott), that informed his attempt the reach the Pole a second time, only to experience failure again. In the first example prepartion was weak, management inconsistent, and lacking an actual strategy, no Plan-B. The second attempt, without Scott, was well planned, well provisioned, well staffed. When trouble started, Plan-B and then Plan-C were put in place and executed.
What's the Point About Managing Projects? So when we hear we're exploring and there is no destination in mind, or named problem to be solved, or even a description of possible root causes of the un-named problem, remember Shackleton's first trip and Scott's mismanagement of that exploration. On the second trip Shackleton had estimated what he would need, what route he would take, what skills his crew needed, what Plan-B would be, and even Plan-C when that didn't work, and most of all he estimated the probability of success to be high enough it was worth the risk to reach the South Pole and return to tell about it. The Polar expedition for Shackleton was a project, planned and executed with credible estimates of every step along the way, including the possibilities hat everything could go wrong and it did. Through is leadership, they lived to tell about it. Related articles Performance-Based Project Management(sm) Released Agile as a Systems Engineering Paradigm 1909 - Ernest Shackleton, leading the Nimrod Expedition to the South Pole, plants the British flag 97 miles (156 km) from the South Pole, the furthest anyone had ever reached at that time. Black Swans and "They Never Saw It Coming" 3 Impediments To Actual Improvement in the Presence of Dysfunction
In the discussions around #NoEstimates, it's finally dawned on me - after walking the book shelf in the office - the conversation is split across a chasm. Governance based organizations and non-governance based organizations.
Same is the case for product development organizaitons. Those producing a software product for sale or providing a service in exchange for money. There are governance based product organizations and non-governance based product organizations.
I can't say how those are differentiated, but there is broad research on the top of governance and business success using IT. The book on the left is a start. In this book there is a study of 300 enterprises around the world, with the following...
Companies with effective IT governance have profits that are 20% higher than other companies pursuing similar strategies. One viable explanation for this differential is that IT governance specifies accountabilities for IT-related business outcomes and helps companies align their IT investments with their business priorities. But IT governance is a mystery to key decision makers at most companies. Our research indicates that, on average, only 38% of senior managers in a company know how IT is governed. Ignorance is not bliss. In our research senior management awareness of IT governance processes proved to be the single best indicator of governance effectiveness with top performing firms having 60, 70 or 80% of senior executives aware of how IT is governed. Taking the time at senior management levels to design, implement, and communicate IT governance processes is worth the trouble—it pays off.
IT Governance is a decision rights and accountability framework for encouraging desirable behaviours in the use of IT. And I'd add the creation of IT, IT products, and IT services. Since IT is a broad domain, let's exclude development effort for things like games, phone apps, plugins. and in general items that have low value at risk. This doesn't mean they don't have high revenue, but the investment value is low. So when they don't produce their desired beneficial outcome, the degree of loss is low as well.
Asessment of IT Governance focuses on four objectives:
In all four, Weill and Ross provide guidance for assessing the capabilities of IT. In all four Cost is considered a critical success factor.
Without knowing the cost of a decision, the choices presented by that decision cannot be assessed. So when we hear #NoEstimates is about making decisions, ask of those decisions are being made in a governance based organization?
Then ask the question who has the decision rights to make those decisions? Who has the need to know the cost of the value produced by the firm in exchange for that cost. The developers, the management of the development team, the business management of the firm, the customers of the firm?
The three dependent variables of all projects are schedule, cost, and technical perfomance of produced capabilities (this is a wrapper word for everything NOT time and cost). The value at risk is a good starting point for deciding to apply governance processes or not. If you fix one of these variables - say budget (which is a place holder for cost until the actuals arrive), then the other two (time and technical) are now free to vary. Estimating their behaviour will be needed to assure the ROI meets the business goals. In the governance paradigm, these three dependent variables are part of the decision making process. Not knowing one of more puts at risk the value produced by the project or work effort. It's this value at risk that is the key to determining why, how, and when to estimate.
What are you willing to loose (risk) if you don't need to know when you'll be done, or what you'll be able to produce on a planned day, or what that will cost, or determine if the ROI (return on investment), ROA (return on asset value), or ROE (return on equity) to some level of confidence to support your decision making - then estimating is a waste of time.
If on the other hand, the firm or customers you work for writing software in exchange for money have an interest in knowing any or all of those answers to support their decision making, you'll likley going to have to estimate, time, cost, produced capabilities to answer their questions.
It's not about you (the consumer of money). To find out who, follow the money, they'll tell you if they need an estimate or not.Related articles Back To The Future Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Danger Will Robinson Some more answers to the estimating questions Capabilties Based Planning, Use Cases, and Agile The Value of Making An Estimate
“I don’t understand why we are going to meet with the team about the new floor layout,” Shannon pushed back. “I mean, it’s a bunch of good guys, but they don’t understand the big picture of work flow and why we need to rearrange things.”
“And, you do?” I asked.
“Well, yes. I watch the unnecessary steps. I watch us move material around four or five times in the storage area before it finally moves to staging a couple of months later. I watch people searching for raw materials in unnumbered bins. I watch people pull unmarked boxes down to see what is inside.”
“Do you think you missed anything? That checklist inside your head, is that all the workflow issues we have? Are you sure you noticed everything?” I pressed.
“Well, not everything. There will always be something,” Shannon shrugged.
“So, let’s turn your single set of eyes and ears into twenty sets of eyes and ears and ask some simple questions of your team.”
These 5 questions need credible answers in units of measure meanigful to the decision makers.
What Does All This Mean?
With these top level questions, many approaches are available, not matter what the domain or technology. But in the end if we don't have answers the probability of success will be reduced.
I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!
For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.
I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.
Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.
Lot's of myth floating around about requirements elicitation and management. Starting with requirements is not how large, complex, mission critical DOD and NASA programs work. Start with Capabilities. This cna be directly transferred to Enterprise IT.
Here's a map of the planned capabilities for an ERP system. This figure is from Performance-Based Project Management® where all the deatails of this and other principles, practices, and processes needed for project success can be found.
Here each business systems capability is outlined in the order needed to maximize the business value. In agile parlance, the customer has prioritized the deliverables. But in fact the prioritization is part of the strategic planning needed to assure that the cost investment returns the maximum value to assure the business receive maintains a positive ROI throughout the life of the project
The first step is to identify the needed capabilities. Here's the steps
Only when we have the capabilities defined for each stage of the project can we start on the requirements. All the capabilities need to be identified and sequenced, otherwise we can't be assured to business goals can be met for the planned investment. With the planned capabilities, we can start on the requirements
With requirements in place for each capability, we can then start development. This is done incrementally and iterative using our favorite agile method. Doesn't mater as long an incremental delivery of value of the approach.
Extensive research has shown given that a current project is more than fifteen percent complete, the overrun at completion will not be less than the overrun incurred to date; and the percent overrun at completion will be greater than the percent overrun incurred to date. Assuming no change in scope or reduction in delivered capabilities, this overrun is locked.
Without knowing the original Estimate At Complete (EAC), the funders of the project have no way of making decisions about the project's total cost, its incremental cost, or how to adjust scope and duration to meet the expected cost incurred in exchange for the expected value produced from this cost. Without this cost information, and related schedule, and techncial performanc information, the notion of decision making is nonsense.
We can't make a decision without knowing the cost and benefits of the resulting decision
The absence of an estimated cost, duration, and delivered capability prevents the business from knowing if they are making the right decision about the investment in the project. So if decision-making is what management does, not knowing this information prevents credible decisions from being made
Not estimating these three data items – cost, schedule, and technical performance (delivered capabilities) – is simply bad business management. What ever unfavorable outcomes – overruns, failed business capabilities, unhappy customers (ACA the most recent example) – is well deserved.
The notion that we can make decision in the absence of estimates of their cost and benefit, appears to be unfounded conjecture, with no evidence of its validity.
I read Technology’s Man Problem in the New York Times this weekend. I thought those days were long gone. I guess not.
Since when it is acceptable to make any comment about anybody’s body part at work? Hello? Are we in the 7th grade? I thought “men” were past that. The gentlemen I know are past that nonsense. So are the gentlewomen. There are reasons I call you my “gentle readers.”
Did you see the statistics in the article?
Among the women who join the field, 56 percent leave by midcareer, a startling attrition rate that is double that for men, according to research from the Harvard Business School.
Unacceptable. Why would you remove half the people who can make your products better? Did you read Here are all the quantifiable reasons you should hire more women? Does that sound like what we do in high tech:
The technical managers I know, know how to write ads that are gender neutral. They know how to interview for cultural fit. They understand that culture is what you can discuss, what you reward, and how you treat each other. They offer jobs that are opportunities, not a long list of tools. (They have read Hiring Geeks That Fit.)
Technical managers, you can be savvy. You can hire people of all kinds. They don’t have to look like you. They can be women, men, young, old, whatever. The more innovation you need in your product, the more diverse you need your team.
You need people who can get along enough with each other to work together, and who can do the work. You don’t need people who are carbon copies of each other.
No other industry would tolerate this sexism or bigotry. Let’s stop it now.
If you are an unseasoned manager, learn how to manage and how hire. It’s not a problem to admit you don’t know. It’s a problem to continue to do it badly.
If you work in an environment where there is sexism or bigotry, stop allowing it. You can stop creating a culture that doesn’t allow women to thrive. You can do your part.
Let’s create an environment in which every person can do great work. No matter who they are. It’s time to manage as if we are all human. The last time I looked, we are.
You’ve landed the interview. Congratulations! Now what?
Make sure you can discuss your value in detail. If you haven’t done so, review your value as in Four Tips to Defining Your Value.
For each and every interview, you want to research the organization and prepare for the interview. You want to understand the questions they might ask you, and be prepared to answer some of the not-so-brilliant questions they might ask.
I’ve covered some of the interview questions I dislike here. See these posts:
You might want to read the interview questions I do like:
You can search this blog for many more interview questions and auditions that I like.
Get ready for the Manage Your Job Search launch this week. I’ll be hosting conference calls this week. The first one, April 10, is a short introduction to personal kanban inside one-week timeboxes. I’ll do a quick intro and answer your questions. Join me?
I recently met someone who thought he could manage his job search with yellow stickies. Given that I recommend personal kanban, I thought we’d be on the same wavelength.
Imagine my surprise when he said, “I have stickies all over my computer, to remind me of what I have to do.”
Oh no. That’s not organized enough. That’s a job search trap.
You can’t organize an emergent project like a job search with stickies all over your computer, any more than you can with a Gantt chart, or a Word file, or a database, or anything else that is static or random. You need an adaptable system, one that allows you to plan just enough for now, but is flexible enough to allow for change, if you need it.
This is why I like personal kanban inside of one-week timeboxes. You have a pull system, where you can see the work, where you constantly move small tasks across the board, and you reflect at one-week intervals. You have a board—or a parking lot—on which to put everything. That means you don’t have to worry when you have a great idea. You have a place to put it.
If you are looking for a job, you need a system, first. I recommend personal kanban.
Do you know about the Manage Your Job Search launch this week? I’m hosting a series conference calls. The first one, April 10, is a short introduction to personal kanban inside one-week timeboxes. I’ll do a quick intro and answer your questions. Sign up for any or all. Hope you join me. They will be fun and informative.
Another definition of economics, closer to software developemnt is the study of how people make decisions in resource-limited situations. This definition matches the classical use of the term and is the basis of software economics. Since software product development always takes place in the presence of limited resoruces. Time, money, capabilities, even knowledge. And since software development always is the exchange of those resources for the production of value, looking at development from an economics point of view is a good start for any discussion around improving the process.
Two other definitions are needed before continuing. Macroeconomics is the study of how people make decisions in a resource-limited situation on a national or global scale. Microeconomics is the study of how people make decisions in a resource-limited situation on an individual or organization scale.
For software development, microeconomics deals more with the type of decision making needed for successful projects. And since much of the discussion these days is about making decisions on projects, let's see how the microeconomics paradigm may improve the communication.
There have been suggestions that the book above is old school and no longer applicable to the modern world of software development - e.g. Agile. Since the book is actually about engineering economics not about software development methods, let's see what the book actually says for those who have not read it, heard Dr. Boehm speak, or in my case worked for the same firm where Dr. Boehm lead our process improvement management effort.
This book was a working text, when I attended USC as a Master's student while working at TRW (Boehm's home) for an Engineering Economics course. The book is still in print and available in used form for low prices. So those wishing to comment on the book, without having first read all 765 pages, can now do so at a low cost.
The preface of the book starts with the usual qualifiers, but contains three important objectives
The major objective of the book is to provide a basis for a software engineering course, intended to be taken at the college senior or first year graduate level
So let's look at chapters to get a feel of the concepts of software engineering economics. My comments on the chapter are in italics.
So What's the Point of All This?
When we hear estimating can't be done for software, we actually know better. It is being done in every software domain. Tools, processes, books, papers, conferences, vendors, professional organizations will show you how.
When we hear this, we now know better.
 "Software Engineering Economics," Barry W. Boehm, IEEE Transactions on Software Engineering, Volume SE-10, Number 1, Januarym 1984, pages 4-21.
 This is the crux of the post, the book and the discussion around the conjecture that we can make decisions about how to spend other peoples money with estimating that spend.Related articles Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices
From the anarchy of gaming coders sitting in the basement of the incubator on 28th and Pearl Street here in Boulder to the full verification and validation of ballistic missile defense system software, 7 miles up the road.
When I hear about how software should be written, how teams should be organized, how budgeting, planning, testing, deployment, maintenance, transiston to business, transistion to production, sustainment, and the myriad of other activities around software development should be done - the first question is always - what's the domain you're speaking about.
Then - have you tested these ideas outside our personal experience. And finally have you tested these ideas in another domain to see if they carry over? If you're just exploring ideas, no problem. But that limits the credibility of the idea to being just and idea with no actionable outcome, other than a conversation. Those paying for the software you are writing for money, usually don't like paying for you to explore using their cash - unless that effort is actually in the plan.
There are of course fundamental - immutable actually - principles for any project based endeavor. These are the Five Immutable Principles of all project success, shown over and again in the root cause analysis of failed projects.
All five of these principles need answers if we're going to have any hope of success. No matter how often it is repeated, insisted upon, or how clever the message is trying to avoid these principles, they're not going away. They are immutable. They need to be answered on day one and on every day until the project is over.
So if we are writing software for money - internal money, external money, maybe even our own money - ask these questions and see if our answers are credible.
More in next post about the economics of writing software for money.