Feats Instead of Processes

In my last post on Software Capabilities and Feats I said that feats are better [to model in a software capability] than processes, because processes are merely organized, consistent, managed ways to accomplish the feat.

A process is one way to accomplish a feat. The feat is the result you want.

Process is constrained by capabilities. So when I am modeling new capabilities, I should not be constrained by existing capabilities. When I introduce the new capability into the wild, the process will need to “re-form” around the new capability.

A process has steps. If we build software capabilities to support a process, we treat the steps of the process like “feats”. I can model a capability to make that step faster or more effective. That assumes that the step is necessary. In order to decide whether a process step is “necessary” I need to understand how it contributes to the valuable result. I need to understand why I do the step. Read more ›

Tagged with: , ,
Posted in Requirements

Software Capabilities and Feats

In some recent conversations, I find that it is hard to explain the notion of a capability. People want to talk in terms of software features or project requirements.

Software capabilities define value in the following ways:

  • enabling the user to accomplish a “feat” in less time than they otherwise would.
  • enabling the user to accomplish a “feat” at a greater scale than they otherwise would.
  • enabling the user (or a group of users) to accomplish a “feat” more effectively than that they otherwise would.
  • enabling the user to accomplish a “feat” that he could otherwise not accomplish at all.
  • enabling the user to accomplish a “feat” better than he otherwise could.
  • enabling the user to focus on “feats” that require decisions, rather than repetitive steps.

Every other benefit of software can be composed from these.

To define value, a software capability must contemplate (model) the “feat” that the user wants to accomplish. Read more ›

Tagged with: , ,
Posted in Requirements

The Other Side of Product Investment

If you are a project manager that does software projects, you deal with the “top side” of product investment all the time. Whether your teams are running agile like scrum or kanban, or whether they are running a phase-gated cycle (waterfall), you are focused on the decisions about organizing the investment into packages for release or deployment. You are running the factory which takes requirements in one end and (hopefully) spits working features out the other. You are working with the analysts or product people to ensure that there are enough requirements, stories, or ideas “ready to start” to keep the team occupied.

But what about the other side of product investment? We often talk about return on investment or ROI, but most organizations only use an ROI project to justify the investment. Some will go as far as to attempt to measure “hard” ROI numbers, but frankly even that is missing half the boat because it is hard to measure the impact of software capability on your organizations top line or bottom line. Without a body count, the best we can do is to infer the correlation of software capabilities to a movement in profitability and assume that the relationship is causal. When it comes to softer benefits like risk reduction, customer satisfaction, or employee retention, there is no reasonable way to measure “hard” ROI dollars. Read more ›

Tagged with: , , , ,
Posted in Software Team

The Perfect Product Road Map

At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:

Capabilities and Adoption.

in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials. Read more ›

Posted in IT Strategy, Software Team

System Replacement Assumptions

I am in the middle of my umpteenth system replacement project.  There are some universal assumptions that are endemic to the user community in every system replacement project.  They are born of hope and frustration.  They are almost universal.

1) The new system will do everything the old one does, only better.
2) The new system will support all of my existing processes and procedures without significant change.
3) The new system will be faster that the old system.
4) The new system will have better data quality than the old system.
5) The new system will address ALL of the shortcomings of the old system.

If you have ever done one of these projects, you know.  They are assumptions that you must actively work against.  They require a constant stream of communication to dispel. I offer you my rationale for why they are never, ever, true. Read more ›

Tagged with: , , , , ,
Posted in IT Strategy, Leadership

Decision Let-down

Leadership must recognize that momentum is lost when decisions are anti-climactic.  As a leader, it is tempting to focus on the decisions as your primary responsibility – but that is only half of the problem.  When decisions are not incisive, are not positive, result in no obvious actions or next steps – our responsibility is to keep the team from getting demotivated, confused, or de-focused.   Read more ›

Tagged with: , , ,
Posted in IT Strategy, Leadership

The Way Forward

Consider this post by Seth Godin… He spends a lot of time describing the negative, which is incredibly helpful when diagnosing our current situation. But he concludes with the game changer – what happens when you do the opposite of all the bad things…

Sometimes it is so easy to see “What’s wrong” with the current picture.  Everyone is a critic.  It is so much harder to say what we should do instead.

George does the opposite

George Costanza (of Seinfeld) famously decided to live by figuring out what he would normally do in any situation and do the exact opposite.

Sometimes our response, when we perceive that the status quo isn’t getting the results we want, is to be somewhat brutal in our critique of the status quo – and then for all the things we find wrong, propose the opposite…

I’m not saying that the opposite is the right thing, but sometimes just thinking through what the opposite might be is a good way to brainstorm through what options you have.  Better yet, look at what others are doing (that is different from your status quo) and think about the opposite of that.

Thinking in terms of opposites is an easy way to get ideas on the table.

Posted in Leadership

Smaller Bets (Story Elaboration Pushback)

It is always better to spend the least amount of (time, effort, money) to get what you want, right?  If I can get a tasty meal for $10 why

McD's Dollar Menu Combo - Buffalo Ranch McChicken + McDouble with Coke = $3.64

McD’s Dollar Menu Combo – Buffalo Ranch McChicken + McDouble with Coke = $3.64

would I pay $30 or $200 – for the experience of eating – that isn’t about taste.  That is a different thing, isn’t it.  We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience.  Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time.  The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.

These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum… Read more ›

Tagged with: , , ,
Posted in Requirements, Software Team

Packing The Box

Do you remember the last time you moved?  Do you remember packing some boxes so full, that they were too heavy to lift after you were done?  It happens.  Especially books and vinyl records.  When you are packing “regularly shaped” high density items, the volume of the box may be too large to contain the weight of the items.  Or it may be that the lifters (I mean you) may not have enough momentary work capacity (strength) to carry the box. Read more ›

Tagged with: , ,
Posted in Culture, IT Strategy, Requirements

Team Behaviors

In my recent post on Optimum Iteration Length, I finished by saying that iteration size is not the cure for bad team behaviors, but shorter iteration size makes those behaviors more apparent.

This post is about how to counteract ineffective team behaviors, from my own experience:

There are three general diseases that have lots of different causes and lots of symptoms, but at the end of the day, they boil down to these three things: Read more ›

Tagged with: , , , , ,
Posted in Leadership, Software Team
Google+