Articles by Rich

In a perfect world, software can be created or purchased that meets all of your requirements. In the world I live in, this is frequently not the case. Often we do not have sufficient time or money to build out against all of the requirements. Likewise, we usually cannot find a software package that meets all of our requirements.

In these cases, we need to decide which requirements are the most important, and which we are willing to do without. Having a formal process for prioritization of requirements can reduce the drama of decision making after it is determined that all requirements cannot be met. Prioritizing requirements is easier when you aren’t already in the position of knowing that you have to compromise. Having a formal process and prioritizing requirements before you know whether they will be able to be satisfied is easier, because it allows the exercise to be “hypothetical”, and therefore objective. It can take some of the “politics” and turf battles out of the decision making domain, because there is less personally at stake in the hypothetical.

So if we agree that we need to prioritize our requirements, and we want to do this before we have a shortfall, how would we do it?

There are any number of possible ways but in reality, it comes down to value. How much, what kind, and who gets it. So let’s talk about a valuation process. Requirements are there because they add some kind of business value. You can’t know how much value until you know how that value is realized, or what kind of value it is.

So lets define the kinds of value you have:

1) Continuation ( I need this to stay in business, to “keep the lights on”, to survive.) These requirements are essential, but they do not have positive value, that is realized when the project is complete. They are liabilities, because not meeting them is a negative result of the project. They can be represented by a portion of the business that is lost because the requirement is not met.

2) Growth – (I need this to grow my business) These requirements are represented by the present value of future growth. While i can’t predict how much I will grow, I can project this, and I can reflect the value of the requirement as a limit on this growth – without satisfying this requirement, I can only acheive 20% of this growth (so the requirement is valued at 80% of the projected growth). Recognize that this can’t really work, because I can have 5 requirements with the same value adding up to 400% of the value of the growth, so you can normalize to the total value of the growth.

3) Cost Savings – (I need this to reduce my operational cost) These requirements are represented by the present value of future cost savings. Each requirements is tied to a valued bucket of savings, and is valued as a fraction of that savings. Without satisfying this requirements I can only save X, Normalize the same as growth requirements.

4) Risk Reduction – risk reduction requirements are realized when you don’t spend or lose money because of some problem that happened. Valuing these is difficult, because they are like an insurance policy. How do you decide how much insurance you need? How do you decide how much you should pay to cover the potential loss? If my annual losses cost millions, this is easy to value, if your losses are small, but the potential is high from a single event, then the value is more difficult to predict. But in the end, they cannot be valued at more than the business is worth. Each requirement then can be valued as a portion of the total loss that you are insuring.

Now lets talk about how to represent this value in a score:

We have a number that is the score for each requirement, we have the value types, so at the minimum, we can total each type, and represent each requirement in proportion to its value type. We must prioritize the value types. How to do this is less scientific. We can look at the total value for each type, but that may not reflect the relative priority or management’s desire. So we can adjust these. Maybe for this project, growth is the top priority. Maybe cost savings. This really is a decision, the requirements and their valuations do not tell us the answer. Decide. You must arrive at a relative weight of these value types.

When evaluating vended software products, there are two explorations that must be done: MetaphorExploration and Capability Exploration. While metaphor exploration helps understand how well the softwares underlying model aligns with the model driving your business practice, the capability exploration helps understand whether the software has capabilities that will enable your business to continue, grow, develop, compete.

Essential to a capability exploration are BusinessCapabilityRequirements. A prioritized set of business capability requirements, can be turned easily into a set of “How will” questions in a vendor RFI. “How will” questions ask the vendor to describe how their software will enable your business capabilities.

Tips:

• Comprehensive: Business capability requirements for a new system must be comprehensive. There is a tendency to focus on current gap or need, rather than total need. This is especially true when replacing an aged system, or when the business model has changed leaving significant capability gaps in the current software product. It is easy to assume that any new system does everything that the current system does. This assumption is rarely valid, even when the new system comes from the same vendor. Make sure that in addition to any gaps or pain points in the current state, you also document the satisfactory and exceeds portions of your current state.

• Open: Business capability requirements for a new system must be open to change or adaptation. Every vendor software will have some specific practices or activities that it does not “do” in the way that your business currently “does”. If your business capability requirements are written in a “closed” fashion (requiring the business activity to be performed exactly as in the current state) may preclude your taking advantages in the software to improve practices or efficiencies. How will questions allow the vendor to show how a practice or activity can be done via their product, and you can evaluate whether that is superior or inferior to your current state.

• Prioritized: Business capability requirements need to be prioritized in terms of some real value derived from the satisfaction of the requirement. You can then also rank the vended product in terms of how much of that real value can be realized via the “how will” pattern demonstrated by the vendor. How you prioritize requirements is also important. PrioritizingRequirements describes different ways of organizing and capturing the relative value of software products or projects. The purpose of prioritization is more to allow you to grade potential solutions according to value delivery, weighting the more important requirements more heavily. This also has the benefit of taking emotion out of decisions. Every decision requires compromise – without a method of valuation that is free from emotion, the decision can be hijacked by political, emotional, or other personal agendas.

Once you have a set of business capability requirements, you can begin to explore the capabilities of different software products that are available. During this exploration, you can learn that you are missing some business capabilities from your list, or some of the business capabilities that you require can be eliminated because they are necessary to your current work process, but not to all reasonable work processes.

You can also map software capabilities to business capabilities, for each vendor or solution. You can rank how well each software capability meets the business capability requirements you have prioritized.

Recognizing that each vendor may have different types of software capabilities that satsify any of your business capability requirements, one of the choices you will have to make is which types of software capabilities you prefer, and whether you prefer a solution with generalized capabilties where a single software capability satisfies many business capability requirements, or one where each business capability is satisfied by a very specific software capability.

After you have explored the various available software capabilities, you can narrow down your search, by refocusing on your software capability preferences, issueing an RFP to the software vendors that you believe to have the solutions that are most closely aligned with your requirements.

When contemplating acquiring software from a vendor, it is important to understand how the capabilities of the organization that you are purchasing from add value to the project, and to the product and your business process over the life of the system. Here are some typical capabilities that vendors provide:

• Software maintenance and enhancement – One of the primary values that purchasing software can provide, are continuing updates and enhancements that the vendor makes to maintain the marketability of the platform. The vendor is under pressure to continue to sell their product to new customers, and therefore must keep the product current and competitive in the market place. You benefit from this because by paying a small annual maintenance fee, you are “entitled” to receive software updates.
• Support Services – No software is free of defects, and certainly every customer of a software vendor will have continuing need to inquire about capabilities of the software. This is typically negotiated as part of an annual maintenance or support agreement through which the customer pays to have the vendor available to fix issues with the software, and answer questions about the software.
• Implementation Services – When installing a software product for the first time there is usually a project to “implement” for each customer. Many customers will pay hourly rates for experts from the vendor to assist them with the implementation of the product. These services can involve analysis, project management, technical installation, and other services.
• Integration Services – If you intend to connect the purchased software product to other systems in use at your organization, often the vendor will participate in building of the connectivity. Many vendors will have pre-existing integration and perhaps partnerships with other vendors in related vertical markets – as well as capabilities to construct bespoke interfaces to systems proporetary to your organization.
• Hosting Services – While this is relatively recent terminology, it used to be “Service Bureau” where the software actually runs an hardware/network infrastructure that is owned/contracted by the software vendor. While this is certainly convenient for smaller organizations that have limited integration requirements – it can present challenges for organizations/systems with significant integration. Focus on platform support – as a separate service from product support, and availability/recovery/business continuity as capabilities of the hoster. Service level agreements for infrastructure problem resolution are typically much shorter than for software problem resolution.
• Bespoke Customization Services – Customers that take advantage of these services, are actually outsourcing their software development. Many organizations with little or no capability of their own find this attractive, and if there is also no capacity to develop requirements, manage projects, or test the resulting product, one is completely reliant on the vendor. Different vendors have different approaches to this – some refuse to build and maintain custom software capabilities that are not “generally releasable” or valuable to the rest of the client base. Others may have another “services” practice that maintains a separate development/project organization around these opportunities. Still other vendors maintain a set of tools or building blocks at the core of their software product(s), that they also maintain a practices of using to solve problems for clients on a consulting basis, or even that they sell these tools to other companies that build product in other vertical markets (not to competitors). Utilizing bespoke customization services, requires that the service be in the best interest of both the customer and vendor, else customer can find themselves unsupported after a warranty period.

Understanding what capabilities you will require from a software vendor is a starting point. Of the capabilities listed here, the hardest to write requirements for is the last. It is extremely hard to assess how capable another organization is at delivering software capabilities.

Starting with an understanding of which capabilties you will request, you can ask potential vendors for their standard policies/contract terms/rates. You can ask for references from customers that have utilized these services in similar ways. My experience is that most vendors who are hungry for new business will over-sell meaning they will promise things that they cannot easily deliver. Ask for examples of similar projects with references and examples of work product. Companies that are restrictive – that want to dictate terms, often are less interested in growing their customer base – this may indicate that they do not find you an ideal customer, or that they are not marketing the product you are interested in agressively. This may indicate that support or supportability of the product is waning, investigate the viability of the company, or the risk of mergers and acquisitions.

Your vendor requirements should contemplate the life of the software product in your company. If your plan is to use it for 5 years, you need to understand the vendor’s 5 year plan. You need to understand the software product and it’s customer base – if you are not close to the center of the customer pack, there is a strong possibility that the rest of the customers will move away from the direction that you are going. Make sure that the product roadmap is in alignment with your near term goals, and the vendors financials will support them being in existence for the projected duration of your reliance on the platform.

In its simplest form, planning is nothing more than sequencing and elaboration; that is, deciding what order to get things done, and then determining a more detailed manifest of work items required to produce each deliverable.

Sequencing: determining the desired order of delivery.

Elaboration: determining a detailed manifest of work items to produce a deliverable.

While I say this and hold it to be true, many will argue that planning is much more than this. To those, let me say this only: If there were no external constraints on the work – and you were the sole stakeholder (like Bill Gates doing a household project) – it would just be sequencing and elaboration. Every other aspect of planning is optimization against external constraints.

I have been saying for several years now that sequencing is a simplification of scheduling. By this I mean that, when I don't have enough information to produce a reliable schedule, I start with a sequence. I do this, so that I can start working to generate the information to produce the schedule. This method works all the time at the beginning of a complex project where people get paralyzed because they don't know where to start.

Today, I flipped this over. Sequencing is not a simplification of scheduling – scheduling is an optimization of the plan to meet an external time constraint. When I think of this, what I realize is that planning starts with a rational sequence of value delivery, and then becomes complex as we optimize to comply with external constraints – time, budget, resource availability.

In the prior post, Units Of Value, I said that defining the units of value is key to understanding and delivering what your customer needs. In order to create a delivery plan, you need to construct a repeatable process for converting units of value to units of work.

This is difficult when a software development process is not very mature, not because the team doesn’t know how, but because the how is different every time. The conversion of what your customer needs into what you are going to build is a solution design exercise.

If my units of value are stories, features, requirements – then my units of work are software components in some framework. Each platform will have different types of components and sub-components. Each unit of value will get a “punch list” – or list of components that need to be built. Some of the components will be shared across units of value, others will be bespoke to a specific unit of value. If there is environment build out (hardware, infrastructure, etc) this is shared across all or most units of value.

There is no right way to do this conversion. There is only consistency, predictability, and integrity. They way to produce these three is to adopt some principles that make sense, adapt your methodology to fit your principles, and refine both your principles and methodology to get better results each time. For this reason, teams that stay together over a series of projects will consistently perform better in this effort than teams that form for a single project and then disband.

Glen Alleman in his Herding Cats blog, asks some really good questions about emergent requirements.  Since Glen is always and forever explaining that domain has everything do do with process, this appears to be another example, where the domain that he is in does not have the same sources of requirements emergence, that the business enterprise has….

In the business enterprise, software is designed to enable a business process by adding capabilities that make human actions more efficient, less risky, and more effective.  But, in enabling the business process, it also changes the business process.  In my experience, this is where the vast majority of requirements emerge from – the building of software capabilities to change the business process, creates new requirements for new or different capabilities.  Why is this so, because once people start to use the new enhanced business process, or start to walk through it on paper or in models, on story boards or in design sessions, they realize the the process enhancements that they had envisioned either did not have the desired effect, or they realize new opportunities to add more value that they had not previously seen.

Simply put business process enhancement is itself an iterative process, with each enhancement.

Since requirements “emerge” in this pattern, we have a choice.  We can ignore the emerging requirements until the current project is complete, but what that creates is a case where the delivery of software capabilities is always a cycle behind the development of requirements for those capabilities.  Isn’t the goal to deliver the capabilities as close to the development of the requirements as possible?

When my customer constantly asks what have I done for her lately, I want to point her at what I am doing for her right this instant – and that is agility: “The ability to respond quickly”

I can imagine that a domain where software capabilities are bespoke to a larger program of capabilities – the software requirements can only emerge from requirements changes in the larger program.

There is power in a name. Primitive cultures often believed that to know the name of something or someone is to have power over it. Much superstition, and "magic" or spell casting has been based in this principle. It fact, even in more modern religions, exorcism can require the name of the possessing power, and certainly the deity that is casting out the demon. You may laugh or ask what does this have to do with leadership?

In our enlightened age, we no longer believe that that kind of power is able to be expressed by invoking the name of some person, object, or power. However, in leadership, there is power in naming things. That is, you can name a practice, a brand, a problem, a role – and in effect by naming it, you are claiming power or authority over it. This is true in the same way explorers and frontiersmen in centuries past claimed land in the name of their king, and named that land, thereby solidifying their claim to it.

Now we recognized that naming is only the beginning of it, and that after naming something, one must define it. One must give it boundaries or shape. One may have to conquer the natives who are "squatting". One may have to colonize it. All of these activities are valuable – but none can be done until the thing has a name.

So why is this important? Because names are important. Names have denotative and connotative meaning, they imply specific meaning. In fact, at times, by naming something, you confer definition, and boundaries and shape to something without intending to. Carelessly naming things can cause confusion, and can make subsequent colonization and conquest difficult. If the name is ambiguous, then it needs to be separated by the definition from the other similar things. If a name is meaningless, then it survives on the establishment of a definition or a brand. If the name is misleading (i.e. you call something by a name that confers the wrong definition, boundary, or shape) then you will spend all of your energy explaining it.

Here are some tips or ideas for naming things:

Problems – Names should express impact and/or cause if known. Often problems are named for symptoms, and this can be misleading. (e.g. Client trades delayed by network firewall outage vs. Trader order entry application is unavailable)
Roles – Names should confer responsibility, more than activity. Often roles are based on industry categories or HR constructs, but may those may not be team or project specific. (e.g. Software Quality Analyst vs. Tester)
Practices – Names should articulate principle and activity. (e.g. Domain Driven Design vs. eXtreme Programming)

So when you have the opportunity to name something, take advantage, and then use the name to drive clarity and urgency into the situation, rather than ambiguity, confusion, or apathy.

Sometimes we need to learn to lead by asking. As a leader, we need to correctly frame the question, so that those we are leading will get the answer themselves.

By asking questions, we are helping those we are leading to draw their own conclusions. In fact, we are providing direction, by asking them to form an opinion.

In truth, this works, whether you are leading from authority, or influence. If you are leading from a position of authority (you are the boss), as it helps develop your staff's self-sufficiency. They learn what is important to you based on your questions. They learn (over time) how to ask the questions of themselves. Your staff take ownership of the answer.

Give this a try. Instead of directing by telling someone what to do and how to do it, ask them "What needs to be done?" and "Why that is important?" Let them articulate their own thoughts on the subject. You can steer their thinking by asking additional questions like, "How are you going to handle this problem?", or "How does your solution accomplish some goal?" These questions allow us to understand and influence their thinking, as opposed to merely directing their doing.

If you are leading from a position of influence (meaning you are a peer or subordinate to those whom you are leading), this also works, because those in positions of authority can take ownership of the answers.

Try this out: Instead of proposing a solution to a problem in front of a group of powerful or politically motivated managers or executives, ask the following question: "What criteria are we going to use to measure the success of any solution to this problem?" or "What goals should we be striving to achieve while solving this problem?". These questions get hidden agendas out in the open where they can be discussed. We can steer this conversation by asking follow on questions like: "Why is that criteria or goal important?" or "How important is that goal or criteria relative to the others?" These questions allow us to expose their thinking, as opposed to proposing solutions or answers and getting shut down by ideas that never made it to the table.

Questions help frame the problem. They help focus attention on decisions that need to be made, problems that need to be solved. Questions allow a conversation to be steered by opening decision points; forks in the road or intersections requiring decision. Questions increase the number of choices. Answers limit the number of choices.
Questions allow us to explore the thoughts of others, where as answers allow us to expose our own thinking.