Posts in  objectives


YAGNI: Ask about actual scenarios even if the features seem reasonable.

Reasonable feature requests

It's difficult in software development to shift the focus to problems and goals instead of features, features, features. As I've written about before, it's ideal to focus on the value first, and match the features to the value.

Sometimes we encounter feature requests that seem reasonable enough that we don't feel the need to back track to discover the value. This happens for many reasons:

  • We've encountered similar requests in the past, maybe with other projects, and it seems natural to add it to the current project.
  • We make assumptions about the value of the feature and the feature seems reasonable to attain the value.
  • We assume what scenarios would prompt the request and assume these situations exist.
  • Sometimes this all happens subconsciously!

Ask anyways

However, I've been surprised how many times:

  • What was needed in a past project wasn't actually needed and all of the sudden it's being added to yet another project under the assumption that it was of value historically. This becomes a self-perpetuating problem!
  • What was of value in a past project isn't of value in a current project.
  • The value isn't what we assume it to is, the problem we think we are solving isn't the same as past problems or the goals aren't the same as past goals.
  • The situations we assume exist probably don't, and even if they do, they may not be the same magnitude of a problem as in the past and thus might not require the same type of solution.
  • Past solutions (features) may not have been ideal.

Just ask!

Just this week I encountered a request that upon further inspection was prompted by a subset of the problems in a past project. Subconciously, I almost implemented the feature with the full set of problems in mind from the past. By inquiring about situations that prompted the request, we were able to create a solution that was a subset of the past solution! This reduced the time and money necessary to deliver value to the customer.

TLDR: Even if a feature seems reasonable, ask about the situations that prompted it. I've often been pleasantly surprised :)


Why analyzing value gets you results.

It's very common to hear from customers, "What will it cost to build X?" Naturally, I want to understand what X will accomplish. I consider this process understanding the value Y, the desired outcomes. Sometimes customers just demand a cost, but for those that are patient in analyzing the value these are the benefits they will reap:

Optimal solutions

My expertise is custom software development. If I don't know about Y I can't leverage my expertise to propose and build optimal solutions to achieve Y. I also don't have the opportunity to point out deficiencies in X. Imagine someone telling their doctor what medication to prescribe.


If you ask for results, you will likely get them. If you ask for features, there's no guarantee of results.

Significantly less wasted time

If I don't understand Y, when X doesn't accomplish it we'll have to try something else. You would be surprised, but when this happens I usually get requests for changes and new features, again with no guarantee of achieving Y. This has happened on every project I've worked on when Y wasn't discussed. Not only does this waste my time, it wastes yours. We are both stuck with the conundrum of who should pay for this wasted time.

Software development is an involved process, it's not just my time. Success requires your involvement in planning, implementation, user feedback, stakeholder feedback, testing, training and many other aspects. It's easy to overlook/underestimate this time commitment. Either way we both lose if we build failed solutions.

Timely results

If we reduce wasted time, you will get results faster.

Reduced cost

Less wasted time means less cost. Identifying and steering clear of low value projects means more of your money can go to high value projects.


Complexity in software happens naturally, simplicity takes expertise. Simplicity brings a whole host of benefits. If the focus is on features, features (complexity) will be maximized.

Maximum value

If the focus is on value, then value will be maximized! Low value features will take a back seat to higher value features.

Minimized maintenance

In my experience, maintenance cost is exponentially proportional to features. Minimal features means minimal maintenance.

If your business needs to make deliveries you could buy a Lamborghini. However, the cost to maintain it will be much higher than many other equally viable choices.

Flexibility to change

The more features the more difficult it will be to introduce and/or change features in the future. For every feature we must be careful not to "break" it with any updates. Naturally, if we don't minimize features, over time it will become very difficult to introduce change. Ironically, I find the features most likely to get in the way are the ones that aren't even used!

Reduced unused features

Do you want to pay to maintain features you don't use?

If I know Y, when your business changes I can make recommendations about which Xs can be removed. If not, in my experience, they never get removed.

Here's a great post on why less code is better.

Reduced training cost

The more features, the harder it is for users to learn to use your software. Keeping things simple for users means less training. Training cost is proportional, probably exponentially so, to features.

Pivoting on effectiveness

If we both know the desired outcomes we can devise simple methods to monitor the effectiveness of the resulting features at achieving the outcomes. When features prove ineffective we can alter/remove them and try other strategies.

Disciplined investment analysis

If we discuss value we can compare it to cost and make sure we're both making a wise investment decision. Without this analysis it's very easy to propose features that can lead to a marginal or negative ROI. In business it takes extreme discipline to make an investment decision. All too often I see everyone wrapped up in features and value takes a back seat. If we make this our focus, it's less likely to happen and you are more likely to see a significant ROI.

Increased investment capacity

This analysis will naturally take longer the first few times it's done. Over time everyone will become more effective and efficient and the time will be significantly reduced. The capacity to make wise investment decisions in software will be magnified!

Free investment analysis

There's ample opportunity for any company to invest in high value projects. Low value work competes for limited resources to develop high value projects. Low value work is unlikely to make you happy, at least not compared to high value work. If you demonstrate an interest in maximizing value, it means we're much more likely to have a successful business relationship and we're both much more likely to prosper. Because of this I provide this analysis process for free. When we're done you will still make the decision if we move forward. That means before I charge a penny you will already be guaranteed to get something of value!

Identify missing perspectives

When discussing value we're likely to stumble upon roles that usually aren't involved until much later, if at all. These roles often provide perspectives that can avoid sub optimal solutions before we even start. One of these roles is the buyer, the person who sets the final expectations of outcomes. Imagine how difficult it is to achieve an expectation for someone you've never met! Also, users of the resulting software are often left out. For example, if we're trying to save time or expand capacity, doesn't it seem like a good idea to involve the person that does the work now?

It's very easy to identify missing roles when we discuss value and run into questions that can't be answered.

Reduced risk

All of these benefits can be had by simply investing in an analysis of value. Once you get good at this it's often only a few hours investment per project. Is it worth the risk to skip this step?


Reaction to: Why your users hate Agile development (and what you can do about it)

I stumbled upon this article this morning: Why your users hate Agile development (and what you can do about it).

The article is a great starting point for at least a dozen conversations. Here are some of my ideas to mitigate the risks the article introduced:

  • Have clearly defined projects based on outcomes.
    • A lack of planning leads to run on development.
    • With waterfall, there is an attempt to nail down features up front. With agile, it's about nailing down objectives and outcomes up front.
    • In my opinion, waterfall fails because it usually focuses on features and not outcomes. When the features don't result in the desired outcome, more work must be done. The same thing will happen with agile unless the focus is first on outcomes.
    • What are objectives? Deliverables should not be the objective.
  • Communicate directly
    • Traditional project management encourages indirect communication through layers of bureaucracy. This is very difficult to change. Many people have faith that this saves time.
    • Nearly every time someone speaks for someone else, I have a follow up question they can't answer.
    • Nearly every time I think I understood what someone said for someone else, eventually something comes up that was miscommunicated or misunderstood.
    • I would never be so arrogant to assume that I can speak for someone else as good as they can speak for themselves. Especially on complex matters like software development.
    • Often when speaking for someone else, the speaker fails to consistently identify who let alone why. There is an attempt to sanitize the content to what they think is important, this is often disastrous.
    • Talk directly to avoid wasting time playing a game of telephone.
  • Involve the buyer
    • The article mentioned that users are often uninvolved, I agree, but I also think the buyer is often uninvolved.
    • With the indirect communication in bureaucratic management, the buyer rarely will represent their expectations to everyone involved. Instead someone else speaks for them.
    • The real expectations (outcomes and objectives) will be lost if the person setting them isn't directly communicating with everyone involved.
    • Compound excluding the buyer with a focus on features. We have one translation from the buyer's expectations (outcomes) to a set of features that may achieve the outcome. Then, another translation of the features to the rest of the team (assuming no more layers of indirection).
      • That's two opportunities for a failure of communication to occur.
      • The person translating objectives to features isn't the expert that builds the feature. They rarely have the experience to draw from to maximize achieving the objective, this is yet another risk.
      • Compound that with any miscommunicated features, which will happen between technical and non technical people, and your risk is through the roof.
      • Add in the reverse process for any follow up questions and you have a disaster.
      • The crazy thing is, all you have to do is involve the buyer directly and all of this risk goes away. And you will save everyone time!
  • Learn to plan just enough
    • Teams new to agile often fail to plan enough. Instead of wasteful upfront planning with waterfall, the opposite occurs. Have patience to learn to balance not enough versus too much.
  • Avoid outcome creep
    • Do not take on a large set of outcomes, and do not let outcomes be added to a project.
    • If a higher priority outcome arises mid project, put the current project (outcome) on hold and switch to addressing the new outcome. However, I would strongly advise against this if timeliness is not of value in the new outcome.
  • Make sure regular reflection occurs
    • At least at the end of a project and each iteration within.
    • Everyone should be involved.
    • If you don't study what worked and what didn't how will you improve?
  • Discuss timeliness
    • Time is a feature, it's not always of value.
    • If time is of value, talk about that up front.
    • Talk about WHY it's of value. Is there risk of losing customers to a new competitor?
    • Otherwise, only talk about ideals, that's the best anyone can do.
    • Communicate regularly about status.
    • Realize that all of the above recommendations will reduce risk and thus reduce wasted time.
  • Budget thoughts
    • This is too big a can of worms
    • However, mitigating the risks above should go a long way towards mitigating budget risk.
    • I personally advocate for an up front investment before taking on a project.
      • Take the objectives/outcomes, analyze value and compare it to the estimated cost.
      • If the ROI is negative there is no reason to take on the project.
      • If the ROI is marginal there is no reason to take on the project.
      • Estimated costs in software development are always subject to risk of what will be learned in the process. Even experts learn, there is no way to mitigate this upfront, embrace it.
      • With the risk in the estimated cost, if the value is not several multiples of the cost, why take on the risk?
    • IMO way too much software is developed without justifying the investment.
      • This inhibits everyone's ability to develop high value software.

Deliverables should not be the objective.


This is pretty common in a software development project:

We want BizTalk, .net, ruby, Nodejs, SQL Server, Sharepoint, Oracle... 


This is pretty common too:

We want a table of customers.
We want an export of invoices. 
We want a list of orders. 
We want the ability to apply discounts. 
We want a report of inventory.


This is very rare:

We want to provide more value to our customers.
We want more customers and to do that we may need to increase the frequency of doing X.
We want to increase customer satisfaction.
We want happier employees.
We want to expand Y and to do that we may need to automate Z.

When I hear this, I know I can make a difference.

Be careful what you maximize

This is my opinion:

Deliverables (ie: features, technologies, software) should be a means to an end.


If you want to maximize business value, the end should be a business objective. If you want to maximize features, technologies and software then let those be your ends.

I'd prefer to minimize features, technologies and software. They aren't cheap to maintain!


Successful software development is about creating value, not software

In my last article “Why objectives and value are important in software development” I gave examples to show that it's important to diagnose before prescribing technical solutions. But what does this entail?

Ask why

Diagnosis can be as simple as asking "why". When someone presents what, ask why. Sometimes the response is more of a what, in which case you may have to dig deeper, keep asking why! This can be like peeling the layers of an onion. At some point you find the center, the core objective.

Successful business objectives create value

Businesses exist to create value. Objectives are guiding principles to create value. For example, most businesses value profit. One objective to create profit may be to expand the customer base. Value is often intangible, for example employee morale. An objective to increase employee morale may be to pursue equitable workload distribution. Objectives are a means to the value (end). Value and objectives are numerous, focusing on them will hone the skills necessary to identify and create value, another reason to ask why.

Assess value

Eventually after peeling back enough layers, you will arrive at a rather fundamental objective.

Let's say someone asks, "Can we generate a PDF of X every night and email it to Y?" Follow up with "Absolutely, but first can we talk about what this will accomplish?" If other people are affected by or invested in the request, involve them too. Make sure to involve the person that will write the check. A typical response might be "Right now John creates this by hand and it consumes a significant amount of time." So we've identified a possible objective, saving time. Again, objectives are a means to an end, in this case it's probably about money.

Objectives often create more than one type of value. Now that you have an understanding of the objective, use it to ask further questions to assess related value. Go grab John and include him too! These are some things you may consider:

  • "How often are there mistakes because it's done by hand?"
  • ask John "Does this drain on your morale?"
  • "How much time will be saved? Over what duration?"
  • ask John "What could you accomplish if you didn't have this burden?"

Involve everyone in this exploration and expand upon what value is desired, quantifying and qualifying it as you go.

Identify investments

With a shared understanding of value, everyone can brainstorm investments in software or otherwise. These options can be analyzed to quantify the level of value they may create and the potential cost. Neither the value nor the cost can be quantified exactly in advance, that's the nature of making investments and taking risk. However, an estimate of a solution without determining if it will create value puts everyone in a much riskier situation. Assessing the value reduces risk.

With enough practice, this approach will hone your ability to make successful investments. Who wouldn't want that?

Also, I'd recommend throwing out any notion of the original request and working from the value to identify solutions. Sadly, the original request is going to bias your thinking, just try not to let it narrow your vision. There are many ways to accomplish an objective and to create value. Keep an open mind to maximize the value.

Further reducing risk with measures

With clearly identified value, the team can find ways to measure how much value is created. In the example above, find a way to measure how much time is saved, count historical mistakes, ask John how we can measure the time or if he already measures it. Measure historically if possible, starting now and going forward. Monitor how things improve (or not). Keep these metrics simple and estimate what it will cost to measure them. Make sure it's worth the investment to measure. A few good measures can help the team improve future value analysis: maybe the value was less than expected, maybe it was more, maybe there was unidentified value.

Maximizing investments

If you don't do this analysis, how can you compare one business investment to another? Some investments are more lucrative than others. Who wouldn't want to tackle the most lucrative of investments first? If you have several pending investments and you've done a value analysis of all of them, you can easily prioritize based on the value!

Since we have a more accurate measure of value and cost, we can prioritize based on ROI. Think about this: if the people who will make the investment have determined that the value they think is possible is low relative to the cost or potentially a negative ROI, why would you make that investment? Likewise, if they have identified a high ROI investment, why wouldn't that be at the top of the list of priorities?

A better approach: objectives first

Though asking why can help you start this process, it's best to start with objectives first. Goals and problems are plentiful, encourage people to track them and bring them to the team as objectives and not as requests. This will eliminate the bias in a particular solution and will eliminate the need to backtrack to the objective.


When doing business, we should assess objectives first, thoroughly ask why, and determine what value we hope to create. Identifying technical solutions should come after, along with an assessment of their value and cost. Successful software development is about creating value, not software.