Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management

Quote of the Month May 2014

From the Editor of Methods & Tools - Mon, 05/26/2014 - 07:50
I’m the Leader. I know what needs to be done and how. This is a very dangerous assumption. While Leaders can be expected to have considerable self-confidence, they are often not aware of all the implementation implications. Source: The Agile Culture, Pollyanna Pixton, Paul Gibson and Niel Nickolaisen, Addison-Wesley

The Three Elements of Project Work and Their Estimates

Herding Cats - Glen Alleman - Sat, 05/24/2014 - 04:38

There is still discussion of estimating that starts with fixing the budget as the solution for No Estimating. This of course simply moves the estimating need to the other two elements of all project work.

These three elements are:

  • The technical and operational capabilities delivered by the project
  • The cost to produce those capabilities on the planned date
  • The schedule on which they will be delivered to meet the needs of the customer on the planned date

Slide1

So when we think about these three elements, how they are coupled, how they interact, what their second tier driver are, we come back to a fundamental — immutable — question

Can We Make Decisions About How To Spend Other Peoples Money In Exchange For Value, Without Knowing The Cost, Duration, or Expected Delivered Value Of Those Activities?

So when we hear there are ways, let's look at them in the context of actual business conditions to see if they hold up to examination. This assumes of course there are actual, actionable, suggestions to making decisions in the absence of estimates.

Related articles Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Resources for Moving Beyond the "Estimating Fallacy" Is There Such a Thing As Making Decisions Without Knowing the Cost? Four Critical Elements of Project Success
Categories: Project Management

Lesson from 40 Project and Portfolio Management (PPM) Leaders

Herding Cats - Glen Alleman - Sat, 05/24/2014 - 04:09

Screen Shot 2014-05-23 at 9.48.06 PM

Get your copy of the lessons from project leaders. Tons of advice of project success, including some from me starting on on page 57.

Related articles Learning from mistakes is overrated
Categories: Project Management

Workshop Visualization (#wallpaper, #noprojector)

NOOP.NL - Jurgen Appelo - Wed, 05/21/2014 - 18:33
slide1

One discussion that keeps popping up among trainers and facilitators is whether to use presentation slides during a course or workshop. The traditional approach is to use them extensively, but a number of facilitators are in favor of a #noslides approach. Some of them prefer to write and draw everything on the spot during their workshops. My own preference is to take a nuanced view between those two extremes.

I think, the question should not be, “Should we use slides or not?”

It should be, “What kind of visualization is the most effective?”

The post Workshop Visualization (#wallpaper, #noprojector) appeared first on NOOP.NL.

Categories: Project Management

Software Development Linkopedia May 2014

From the Editor of Methods & Tools - Wed, 05/21/2014 - 12:22
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about project estimation, how software developers feel about Agile, unit testing worst practices, team leadership, giving feedback in Scrum, software architecture, using commercial load testing and Scrum tools for free, sustainable Agile and data models for NoSQL databases. Blog: Paying the Cost for More Precise Estimates Blog: Where did all the developers go? Blog: Getting Unit Testing to Fail Blog: Real Teams Have Leaders! Blog: The Software Chicken and ...

Paying the Cost for More Precise Estimates

Mike Cohn's Blog - Tue, 05/20/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver. There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate. I will be happy to provide a boss with that information.

So long as the boss understands that information has a cost.

I don’t mean the boss has to slip the team a $20 tip. What I’m referring to is the time the team will spend creating that estimate.

If a boss wants a really quick, down-and-dirty estimate of when a set of features will be done, I can answer that instantly. My answer: in the future. It’s certainly accurate.

But, it’s probably not what the boss is looking for. (And don’t blame me if you get fired for trying that answer!)

Perhaps a better estimate is needed. So the team puts more effort into estimating and thinks harder about what’s being asked for. They may come up with something like, “Three to six months.” That’s certainly better than “in the future.” And often, it’s good enough for decisions like, “Should we start this project?” and, “Should we add more teams?”

But, many bosses will insist on something more precise—perhaps an answer like, “In August.” Note that telling your boss a month is still framing your estimate as a range, which is vital to giving an accurate estimate. But, it’s much more precise than saying, “Three to six months.”

To add precision to an estimate requires time. And that is the cost I’m referring to.

As long as a boss is willing to pay that cost, a good team should be willing to provide an estimate at whatever level of detail and precision the boss wants. The problem is when the boss wants a highly precise estimate and isn’t willing to pay the cost, for example, “I need to know by lunch time today exactly when this large project can be delivered.”

When asked by a boss to provide an estimate you’d prefer not to provide, do not argue with the boss that the estimate is unnecessary. That will usually get you nowhere. Instead take the attitude that you’re happy to provide the estimate (even if you aren’t), but challenge the boss about how precise or detailed the estimate needs to be.

If providing the estimate will cause all other work to stop for a week, the boss needs to understand that. If the boss has a true need for the estimate, he or she may be willing to let all other work stop. If the boss just wants an estimate to feel good or to hold the team accountable, the boss will probably settle for an easier-to-provide but less precise estimate.

Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information.

Paying the Cost for More Precise Estimates

Mike Cohn's Blog - Tue, 05/20/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver. There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate. I will be happy to provide a boss with that information.

So long as the boss understands that information has a cost.

I don’t mean the boss has to slip the team a $20 tip. What I’m referring to is the time the team will spend creating that estimate.

If a boss wants a really quick, down-and-dirty estimate of when a set of features will be done, I can answer that instantly. My answer: in the future. It’s certainly accurate.

But, it’s probably not what the boss is looking for. (And don’t blame me if you get fired for trying that answer!)

Perhaps a better estimate is needed. So the team puts more effort into estimating and thinks harder about what’s being asked for. They may come up with something like, “Three to six months.” That’s certainly better than “in the future.” And often, it’s good enough for decisions like, “Should we start this project?” and, “Should we add more teams?”

But, many bosses will insist on something more precise—perhaps an answer like, “In August.” Note that telling your boss a month is still framing your estimate as a range, which is vital to giving an accurate estimate. But, it’s much more precise than saying, “Three to six months.”

To add precision to an estimate requires time. And that is the cost I’m referring to.

As long as a boss is willing to pay that cost, a good team should be willing to provide an estimate at whatever level of detail and precision the boss wants. The problem is when the boss wants a highly precise estimate and isn’t willing to pay the cost, for example, “I need to know by lunch time today exactly when this large project can be delivered.”

When asked by a boss to provide an estimate you’d prefer not to provide, do not argue with the boss that the estimate is unnecessary. That will usually get you nowhere. Instead take the attitude that you’re happy to provide the estimate (even if you aren’t), but challenge the boss about how precise or detailed the estimate needs to be.

If providing the estimate will cause all other work to stop for a week, the boss needs to understand that. If the boss has a true need for the estimate, he or she may be willing to let all other work stop. If the boss just wants an estimate to feel good or to hold the team accountable, the boss will probably settle for an easier-to-provide but less precise estimate.

Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information.

Paying the Cost for More Precise Estimates

Mike Cohn's Blog - Tue, 05/20/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver. There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate. I will be happy to provide a boss with that information.

So long as the boss understands that information has a cost.

I don’t mean the boss has to slip the team a $20 tip. What I’m referring to is the time the team will spend creating that estimate.

If a boss wants a really quick, down-and-dirty estimate of when a set of features will be done, I can answer that instantly. My answer: in the future. It’s certainly accurate.

But, it’s probably not what the boss is looking for. (And don’t blame me if you get fired for trying that answer!)

Perhaps a better estimate is needed. So the team puts more effort into estimating and thinks harder about what’s being asked for. They may come up with something like, “Three to six months.” That’s certainly better than “in the future.” And often, it’s good enough for decisions like, “Should we start this project?” and, “Should we add more teams?”

But, many bosses will insist on something more precise—perhaps an answer like, “In August.” Note that telling your boss a month is still framing your estimate as a range, which is vital to giving an accurate estimate. But, it’s much more precise than saying, “Three to six months.”

To add precision to an estimate requires time. And that is the cost I’m referring to.

As long as a boss is willing to pay that cost, a good team should be willing to provide an estimate at whatever level of detail and precision the boss wants. The problem is when the boss wants a highly precise estimate and isn’t willing to pay the cost, for example, “I need to know by lunch time today exactly when this large project can be delivered.”

When asked by a boss to provide an estimate you’d prefer not to provide, do not argue with the boss that the estimate is unnecessary. That will usually get you nowhere. Instead take the attitude that you’re happy to provide the estimate (even if you aren’t), but challenge the boss about how precise or detailed the estimate needs to be.

If providing the estimate will cause all other work to stop for a week, the boss needs to understand that. If the boss has a true need for the estimate, he or she may be willing to let all other work stop. If the boss just wants an estimate to feel good or to hold the team accountable, the boss will probably settle for an easier-to-provide but less precise estimate.

Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information.

Quote of the Day

Herding Cats - Glen Alleman - Tue, 05/20/2014 - 04:05

“If a man gives no thought about what is distant, he will find sorrow near at hand.”
— Confucius

When you hear that we can't make estimates, we don't need to make estimates, we don't want to make estimates, because somehow, some way, they are the smell of dysfunction. Think of this quote.

If we don't now what the cost of our work will be in the end, when that work will be complete, what will be produced from that work — and most importantly of that work will actually produce what those paying us to do the work need to do their work — then we're likely going to come to grief.

Categories: Project Management

Top 200 Management & Leadership Authors (Maybe Not Experts)

NOOP.NL - Jurgen Appelo - Mon, 05/19/2014 - 12:57
top 50

Several weeks ago, I wanted to know who are the most interesting management & leadership writers (worldwide, in the English language). Which authors should I follow? Which blogs should I read? What books do I add to my backlog? Which writers have a great reputation? Of course, a not unreasonable secondary objective was to learn how does my work compare to the others? As I always say, how do you know you’re making progress when you don’t measure?

The post Top 200 Management & Leadership Authors (Maybe Not Experts) appeared first on NOOP.NL.

Categories: Project Management

To Stay In Business You Need to Know Both Value and Cost

Herding Cats - Glen Alleman - Sun, 05/18/2014 - 00:08

Show-me-ROI
I hear all the time, in agile we focus on value generation. Any viable business focuses on producing value for its products or services. Saying that is a tautology. There can be no viable business without some kind of value proposition that is acceptable to some number of customers to produce enough revenue to cover the costs of producing that value.

But not knowing the cost of that value, the cost to produce that value, managing the cost to produce that value, and controlling the costs during the value production process - There is not sustainable business

And by the way, the date on which that value will appear, since revenue stream or benefit stream needed to pay for the cost of that value needs to start on the planned time to produce the planned business performance needed to stay in business. Nice products late or nice products for too much cost is a going out of business strategy.

The next time you hear, we focus on value first, call BS. Focusing on value in the absence of focusing on cost of that value is a going out of business  strategy (unless you're a sovereign).

In the bottom line management of any viable business you get a divide by zero error if you don't know the cost of the value produced.

Since both value and cost are random variables in any development business - and random variables on production business as well - we need to have estimates for both cost and value at the same time. These estimates need confidence levels, cumulative probabilities of being at or below and on or before conversations. And an understanding of how the work processes drives these random variables as the project or service proceeds.

It can't be said any more clearly

Both Value and the Cost of that Value are needed for any hope of staying in Business

So don't let those asserting we focus on value to get away with that weak statement. Producing products for money is driven by the business processes first. Those producing those products need to get paid.

And when we here, don't estimate budget, then we're fixing one for the three variables of all projects, and the other are still free to vary in random ways. These ways need to be estimated as well, otherwise that fixed budget, may or may not be enough to deliver the needed capabilities on the needed date to deliver that needed value.

Slide1

Related articles Four Critical Elements of Project Success Everything is a Random Variable
Categories: Project Management

Spike It! Article Posted

One of my clients was having trouble with estimating work they had never done before, so I wrote an article explaining spikes. That article is up on agileconnection: Need to Learn More about the Work You’re Doing? Spike It!

It was a little serendipity; I taught an estimation workshop right after I explained how to spike in email. That article almost wrote itself.

You can use a spike in any project, agile or not. Spikes are for learning.

I also explain what to do when managers say, “Use the code in the spike” and you think, “Oh no!” See for yourself.

Would-be authors: want to write an article for agileconnection.com? I’m interested.

 

Categories: Project Management

Interview with Esko Kilpi

NOOP.NL - Jurgen Appelo - Fri, 05/16/2014 - 14:21
esko-kilpi

As part of my global book tour I hope to have fascinating conversations with management & leadership experts around the world. One of them is Esko Kilpi, a researcher and consultant in Finland who has a focus on the “arts and sciences of complex interaction”. With Esko I talked about management & complexity.

The post Interview with Esko Kilpi appeared first on NOOP.NL.

Categories: Project Management

45 New Books (by Top Authors) for Your Management Book Shelf

NOOP.NL - Jurgen Appelo - Thu, 05/15/2014 - 16:38
books.jpg

You may have seen that I supplied the data for Inc.com’s Top 50 Management & Leadership Experts. People seem to like it very much.

Well, what I also did was find the answer to the question, “What are the latest book releases of the management & leadership experts?”

I discovered new books by Tim Harford, Daniel Kahneman, Dan Ariely, Henry Mintzberg, Jason Fried, Simon Sinek, Peter Senge, Malcolm Gladwell, Chip & Dan Heath, John Kotter, Clayton Christensen, and many more… My reading backlog just doubled in size!

The post 45 New Books (by Top Authors) for Your Management Book Shelf appeared first on NOOP.NL.

Categories: Project Management

Better Management with Fewer Managers (video)

NOOP.NL - Jurgen Appelo - Thu, 05/15/2014 - 11:40
book-trailer

In modern businesses managers are expected to be “servant leaders” and “systems thinkers”. But nobody explains how they can do this tomorrow morning. “Empowering workers” and “delighting customers” are important principles. But none of those suggestions are concrete. Most people want to know…

The post Better Management with Fewer Managers (video) appeared first on NOOP.NL.

Categories: Project Management

Design Your Agile Project, Part 5

This post is what you do when you are a program manager and not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change? (In the book, I will talk more specifically about change and what to do. This post is the highlights.)

Project management and program management are all about managing risks. How do we bring the management of change and management of risk together in an agile project or a program?

Let’s review the principles again:

  1. Separate the business decision for product release from the software being releaseable all the time. That means you want the software releaseable all the time, but you don’t have to release it. I talked about this in Design Your Agile Project, Part 1.
  2. Keep the feature size small for each team, so you can see your throughput.
  3. Use the engineering practices, so you don’t incur technical debt as you proceed.
  4. Understand your potential for release frequency.

Are you doing these things now? Are they part of how you work every day? If not, you need to change.  I’m going to address what the program needs to do to succeed.

Your Program Represents the Teams

In a sense, the program will represent the state of agile for the teams. Think of it as Conway’s Law exposed. (Conway says the system design reflects the communication structure of the designers.)

You might think you need to standardize your approach to agile or lean. You might think you need to be rigid about how you move to agile.

You would be wrong about the process. You would be more correct about the engineering practices.

You need to create the most resilience for the organization. Here’s what I mean.

CynefinIf you have autonomous, collaborative teams, you will have uncoupled, collaborative code. If you look at the Cynefin framework, you get that on the right side, without too much trouble. (I’m not saying this is easy. Just that it’s more possible.)

But, what if you have geographically distributed teams, or your teams are new to agile/lean, or you are still responding to requests from all of the program because the rest of the organization doesn’t quite understand agile? What happens then?

You are on the Complex or Chaotic side of the Cynefin framework. Maybe you don’t use the Good Practice that we already know for program management, right? Maybe you don’t use what we already know about for the projects, because they won’t scale for the program.

That’s why each team needs to review Part 2 and Part 3, especially if they are part of a program.

That’s why program management needs to be servant leadership at the core team level. See Which Program Team Are You Managing? Some program managers think they are managing technical teams. They might be. But, they might need to manage a core team in addition to a technical team.

What Does this Mean for a Program?
  1. If you are trying to change everything, you have many unknowns. You are not in the right side of the Cynefin framework. You are somewhere on the left side of the framework. Agile “out of the box” is not going to work.
  2. Teams need to practice being agile as a team, before they are part of a program. They can come together in service of a program. And, because each team designs its agile project, no manager can change people on a team, unless the team requests that change. No “I can move people like chess pieces” business. Managers serve the teams.
  3. Beware of hierarchies. They will slow your program. What is a hierarchy? Scrum of scrums. Hardening sprints, especially where other release teams integrate for the feature teams, can create hierarchies. Why? Because it’s too easy to say, “My part is done.”

If you are designing your agile project to be part of a program, you want to consider, “How will we make sure we deliver on a consistent basis to the rest of the program?”

This is not about maximizing throughput. This is about meeting deliverables, and making sure that the teams know about their interdependcies long enough before they have to meet them. Then, the teams can meet them.

In a program, you always have interdependencies. Always.

Design Each Team’s Project to Optimize at the Program Level

If you are part of a program, it’s not enough to design your project for your team. You have to consider the needs of the program, too.

Each team needs to ask itself, “How do we deliver what the rest of the program needs, as the program needs it?”

You might want to watch Phil Evans Ted talk, How Data Will Transform Business. In a hierarchy, we have too-high transaction costs. (In geographically distributed teams, we have too-high transaction costs, too, but that’s a different problem.) Note how he says “Small is Beautiful.” Hehehehe. Gotta love it.

Hierarchies are slow to respond. They impose barriers where you don’t need any. The problem with programs is that they are big. You want to decrease the problems of bigness where you can. One way to do that is to decrease the effects of hierarchy. How? By not involving hierarchy whenever you can. That means using small world networks to solve problems between and among teams. That way you solve problems where the problems exist.

If I ran all the programs in the world, what would I do?

  1. Have feature teams everywhere, not geographically dispersed project teams. I prefer collocated teams, but I realize in very large programs that is not always possible. (Sigh.)
  2. Have a core program team (cross-functional business team) that runs itself using kanban. If you need a cadence, use a one- or two-week iteration for the team’s problem-solving.
  3. For the technical program team, run itself using kanban. Same idea with problem-solving cadence.
  4. Have the project teams use their own approaches to agile and lean, recognizing that their job is to reduce batch size, get to releaseable all the time, and not incur any technical debt as they proceed. The more the project teams are autonomous in their approaches to agile, the more they will collaborate with each other. The more they will feel free to explore what they can do.
  5. Have the program architect (who represents the business value to the core team) look for examples of bad implementations of Conway’s Law all the time in the product. That will help create architectural business value. Yes, there is more that the architects do.
  6. Encourage Communities of Practice for the functional areas. Encourage cross-pollination between the communities. The “plain” developers need to know what the architects are thinking, as do the testers. The developers need to know what problems the testers are solving, and so on. Organizing and facilitating CoP might be a management job. It might be a program management job. It’s a servant leadership role. It’s definitely not a command-and-control role. (“It’s Tuesday at 4pm. It’s time to learn.” Ugh. No.) The word here is “encourage,” not mandate.
  7. As a program manager, you need to be aware when people need more training in understanding deliverables or what those deliverables are. Do they understand flow? Do they understand agile? Do they understand feedback? Do the teams need coaches? Do the teams need help in project management (yes, the teams are doing project management)? Do the teams need help in agile or lean? Do the teams need help in the interpersonal skills? Do the teams need help in the engineering practices that will help them deliver a clean feature every day or so into the code base?

Those are just your deliverables to the program. That’s nothing about what you deliver to your management team.

Keep these three words in your pocket for your teams: autonomy, collaboration, and exploration. The teams need to be autonomous. It’s their deliverables that you care about. Not the teams being in lock-step.

You care about the teams collaborating. How do you encourage that? With small features and product owners who have well-defined feature backlogs and roadmaps. The more often the teams check completed features in, the fewer collisions, and the more manageable the collisions are. You get momentum that way. I talked about momentum in Organizing an Agile Program, Part 3, Large Programs Demand Servant Leadership.

The exploration occurs when the teams (which include architects) spike or explore what the team(s) think the options are. Or, when teams talk among themselves to solve problems. Teams can first solve problems themselves. They do need a small world network and to know that you want them to solve their problems. They don’t need a hierarchy to solve problems. These people are smart. Isn’t that why you hired them?

Okay, all the previous posts in this series are:

Design Your Agile Project, Part 1

Design Your Agile Project, Part 2

Design Your Agile Project, Part 3

Design Your Agile Project, Part 4

Sorry this series took me so long. Travel and our new house interfered. Being a product owner is all-consuming.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 05/14/2014 - 16:15

Again and again and again – what are the facts? Shun wishful thinking, ignore divine revelation, forget what ‘the stars foretell’, avoid opinion, care not what the neighbors think, never mind the unguessable ‘verdict of history’ – what are the facts, and to how many decimal places?   You pilot always into an unknown future; facts are your single clue.  Get the facts! ~ Robert A. Heinlein (1907-1988)

So why do we hear conjecture, unsubstantiated statements, suggestions without actionable outcomes, obvious nonsense about how to spend other peoples money?

Facts must be harder to come by than it looks.

Categories: Project Management

Four Critical Elements of Project Success

Herding Cats - Glen Alleman - Tue, 05/13/2014 - 16:27

Four core components must be in place, have credible values, be used to make decisions, be connected to the actual performance of the project in a closed loop feedback system for the project to have any hope of success.

Screen Shot 2014-05-13 at 8.20.08 AMSCHEDULE

Without a sequence of the work to be performed, some knowledge of how long it will take to perform each of those work elements, there is no way to know when the project will be complete.

There are many ways of discovering the work, its duration and the sequence of this work. The approach to answering these questions is dependent on the domain, value at risk, and the needs of the customer. 

It is the needs of the customer that anchor the selection process, not the providers of services to those customers. This is a repeated theme here. Those providing the money to do the work have a vested interest in how the work is performed.

Screen Shot 2014-05-13 at 8.20.19 AMCOST

The value of the produced outcomes is dependent of knowing something about their cost. This is a fundamental principle of all business and is the same for project work.

If we have some notion of value, either through the customers opinion or through and actual business modeling process, we need to know the cost of producing that value.

Since all variables on projects are random varaibles, our cost estimating processes must be applied to reveal the could costwill costshould cost aspects of these deliverables. 

One approach to cost estimating is Reference Class Forecasting. Other approaches can provide credible estimates including parametric modeling. Tools, processes, formal guidance are all available for estimating cost in nearly every business and technical domain. 

Guessing is not estimating, ignoring the cost of performing the work is negligence, claiming costs can only be known at the end to the project is ignorance.

Screen Shot 2014-05-13 at 8.20.27 AMRISK

All risk comes from uncertainty

Risk management is how adults manage projects - Tim Lister

Unmanaged risk will not go away, it is always there. The management of risk starts with a list of risks, the risk register. This list states the probability of occurrence, the probability of impact, the cost to handle the risk, the residual probability of the risk once it is handled. 

The risk management processes is explicit and follows a step-by-step process. Some development processes like agile can increase the visibility to the reduction of risk, but they are not risk management processes, just contributors to the risk reduction and handling processes.

Screen Shot 2014-05-13 at 8.20.34 AMUNCERTAINTY

 All project variables are random variables, act accordingly.

Knowing the underlying probability distribution functions of the statistical processes driving these random variables is a critical success factor for all project.

Anyone seeking or suggesting there is certainty on projects has failed to pay attention in their High School statistics class.

Every cost, schedule, and technical performance parameter on every project has a probability distribution assigned to it. Without knowing or understanding that distribution, or that the distribution is present, will lead to unanticipated cost, schedule, and technical performance disappointment.

So Now What?

  • We can't make decisions without knowing the cost of those decisions.
  • We can't know those costs without making estimates. Waiting till the end is not a viable business process.
  • All work we do is probabilistic in nature. We need margin to cover that work whose variances can't be reduce. We need risk buy down activity for those we can.
  • Measures of Effectiveness and Measures of Performance are what the customer is most interested in at a planned cost for the value being delivered

 

Related articles Everything is a Random Variable Elements of Project Success Let's Stop Guessing and Learn How to Estimate More Uncertainty and Risk Unceratinty and Risk How to Forecast the Future What's Gonna Cost and When Will We Be Done? Is There Such a Thing As Making Decisions Without Knowing the Cost?
Categories: Project Management

Are You Running from Problems or Solving Them?

Back when I was a manager inside organizations, I had many days that looked like this:

  • Meetings at 9am, 10am, 11am.
  • Working meeting through lunch (noon-1pm)
  • Meetings at 1pm, 2pm, 3pm.

I finally got a chance to check my email at 4pm. That’s when I discovered the world had blown up earlier in the day! (This is before cell phones. Yes, there was a time before cell phones.)

I then ran around like a chicken with my head cut off until I left work at 5:30pm, because, yes, I had a family, and, yes, I had to leave at 5:30pm. I either made dinner or picked up children, depending on my agreement with Mark.

We did the family stuff until 8pm, and when the kids went to sleep, I went back to work.

No wonder I was exhausted. My decision-making sometimes suffered, too. No surprise there.

Luckily, I had some days that did not look like this. I could solve the problems I encountered. And, some of these meetings were problem-solving meetings.

However, I had jobs where my senior managers did not manage their project portfolios, and we had many crises du jour. My VP would try to catch me on the way to my next meeting, and attempt to get me to “commit” to when a patch would be available or when we would start, or finish a project.

I swear, one of my VP’s used to know when I went to the ladies’ room. He did yell at me through the door, just as in this management myth.

I finally put my foot down, and said I was no longer going to meetings that weren’t problem solving meetings. Have you read the chapter about meetings in Manage It! Your Guide to Modern, Pragmatic Project Management? I wrote it for project managers and for managers who run around like the proverbial chickens. I wrote Manage Your Project Portfolio for managers like me who had well-meaning senior managers who had trouble making decisions about which projects to do.

This management myth is something I see often in organizations. This one is the one where people are running around so often they don’t actually solve problems.

Many problems are a combination of several problems. You might have to separate the problems and attack them in sequence. But, you might have to see the whole first, because there might be delays. The overarching problem is this: if you don’t give yourself enough time as a problem solving team, you can’t tell what the problem is. If you can’t tell what the problem is, you can’t solve it.

Problem solving tends to go through the process of:

  • Problem definition: What do we think the problem is?
  • Problem discussion: Let’s get all the divergent ideas on the table. Brainstorm, whatever we need to do.
  • Select a solution: Converge on a solution, trying out the ideas, understanding the results of each potential solution
  • Determine an action plan, with dates and people’s names associated with each step

Your problem solving might vary from this a bit, but that’s the general idea.

If you never give yourself enough time to solve problems because you’re always running around, how can you solve problems? It’s a problem. (Like the recursion there?)

That’s this month’s management myth, I Can Concentrate on the Run. Maybe your myth is that you can concentrate in a 10-minute standup. Maybe your myth is that you can concentrate on your drive into work. You might be able to, for some problems. Complex management problems require more than one person to solve them. They require more than a few minutes thought.

How do you solve complex problems in your organization? Do the problems run around the organization for a while? Or, do you solve them?

Categories: Project Management

Commitment Is Easy, Persuasion Is Hard

NOOP.NL - Jurgen Appelo - Mon, 05/12/2014 - 10:18
Commitment is Easy

Several weeks ago, almost 100 people answered to my call for beta readers for my new book. That was far more than I had expected. However, I suspected that some of them were perhaps a bit too enthusiastic. That’s why I decided to ask all 100 volunteers these tough questions:

Can you give feedback on 250 pages of text in only 3 weeks?

The post Commitment Is Easy, Persuasion Is Hard appeared first on NOOP.NL.

Categories: Project Management