Articles from July 2011

Following a twitter conversation recently, Matthias Weimann posted a quote from Clay Shirkry about process:

“Process is an embedded reaction to prior stupidity” – Clay Shirky

and it started. Scott Ambler – one of my favorite Tech authors replied:

There is always a process being followed.
Your process may or may not be documented, or even recognized by the people following it.

and it started me thinking.

A person who is performing an activity is either following a process or he is inventing one. You can’t “follow” a process that has never been invented. Invention may be simply combining elements together from other processes, but it is not following.

A group performing an activity is either following a process or they are collaborativey inventing one. The collaboratively inventing is messy. It typically involves arguments and disagreements. These collaborators will continue to invent like this until one or more get tired of the mess – they they recognize and documents elements of process to reduce the clutter of invention.

A manager looks at the mess of invention, he foresees chaos, unpredictability, disaster. He also foresees his own responsibility for same chaos and disaster and proclaims, “This cannot continue”. Shirky implies an incompetent manager who waits for the disaster to occur, but competent managers try to impose controls before the disaster occurs. 

A leader will join the fray and guide the chaos, gradually reducing the mess, so that we don’t continually reinvent the process over and over.

Design is the great time to assess the impact of a software change. I want to talk about three aspects of impact that we should consider:

Business Impact: Any material change to the business process that is not specified in the requirements should be considered impact. This could be beneficial or detrimental, or value neutral – it is still change. If each user needs a second monitor on their desk, this is impact. If two steps are removed from the process, this is impact. If users now need acess to and training for an additional system in order to complete a process, this is impact.

Business impact is important because the changes need to be planned, and paid for. The user community needs to be able to accept or reject this impact. It should not come as a surprise.

Software Impact: Any material change to the software that is not explicitly specified in the requirements is to be considered impact. If the data model changes in ways that require an adjustment to software capabilities so that they continue to work correctly, this is impact. If the design calls for a change to a shared service, such that all other consumers of that service must adjust or ensure that they are still operational, this is impact. If the design requires a change to an interface language (i.e. XSD), then every application that participates in that interface language must change.

Software change is important because the collateral impact may create additional coding effort that was not originally considered, even beyond the boundaries of the application that is changing. Additionally, this can simply add additional scope to regression testing, to prove that changes to central/common code components do no harm to unchanged features.

Environmental Change: Environmental change is rarely if ever specified in requirements, however, design often proposes change to infrastructure. Storage space, or other system resources, new servers, even external conectivity all are typical environmental change. Occasionally, non-functional requirements can predict environmental change like requirements to improve performance. Likewise requirements to get data from external sources can expose needs to build connectivity.

The importance of this impact is pretty clear. The provisioning of these resources is work in the project plan that needs to be planned. It also adds complexity to testing and deployment.

In UnitsOfWork, I talked about how teams who stay formed through a series of projects become better at converting units of value to units of work consistently. While re-reading this post, I realize that a great fallacy of the PMO is that it is not the project manager who is responsible for this process, but analysts and technical resources who make up a software development team. They key point of a PMO is to provide the consistent planning process so that the organization can form, disband, and reform teams to complete projects.

For the past few years, I have run something like a PMO. I managed a pool of analysts and project managers and testers that were assigned to virtual teams. I tried repeatedly to establish repeatable practices around planning and estimation. I established (with my project managers) standard practices around these. The two biggest frustrations the project managers were that the business stakeholders did not have a consistent practice for reflecting UnitsOfValue in requirements, and that the analysts and architects did not have a consistent practice for converting units of value into Units Of Work.

I am not saying that the projects or the project managers weren’t successful – most of them were. Good PM’s know how to wrestle a plan to the ground and make it tap out. What I am saying is that the practice of forming and disbanding virtual teams for each project is orthogonal to the development of a consistent repeatable planning practice, because of the project manager is not directly responsible for these two key inputs into the planning process.

The theory of having individuals grow together to refine a set of practices toward consistency when every project has different individuals is the opposite of what a PMO does. What the PMO does is to construct a set of theoreticals, and one or more flavors of project practices to cover different types of projects, and push these practices, top down, into the field. It (typically) does not get feedback from every project to improve its practices, because its focus is on driving consistency at a high level into all projects to improve organizational capabilities around governance, rather than driving consistency, predictability, and repeatability into every team, to improve the execution of every project.

Software design is all about decisions. What language or platform is best suited to solve the problem? What pattern(s) will we adopt? What components need to be built? What layers are required and what will each layer be responsible for?

In a “good” software design, decisions are made efficiently. That means that we make decisions as little as possible. Stated differently, we try not to make the same decision over and over for every situation, but rather to generalize our decisions, forming guiding principles for the remainder of our design.

In order to generalize decisions, and to decide efficiently, we have to have some method for “prioritizing” or “sequencing” our decisions. We need a way to reflect the relative impact of a decision (the cost of changing our mind). We also need a way to reflect dependencies between decisions. I like to use two measures to accomplish this:

• Scope – this is a measure of how much of the application is affected by this decisions. So the scope might have the following values: Component, Feature, Layer, Subsystem, System, beyond. The purpose of this is to understand “potential impact zone” for changing this decision.
• Time Span – This is a measure of how much work or time it will take to unwind a decision once made. It correlates to cost. The higher cost of the decision, the more certainty with which I want to make it. Of course these are estimates, but if it takes me 3 months to build something, and I have to build over because of a bad decision, the time span could be 3 months… It could be more, it could be less. The zone of impact tells me that even things that aren’t directly affected could be affected.

When I look at my design, one of the things that I do is to try to reduce the scope and time span of my decisions through layering, and encapsulation. Basically, designing in ways that minimize the scope of each design decision. Why? Because it reduces the risk of bad decisions! All those design principles that we learned (separation of responsibility, etc) are really isolating design risk in as small an impact zone as possible. For the most part, it reduces the cost of screwing up. Is it the fastest way to produce software? No – In most cases, it increases overall software complexity, in order to simplify and remove risk from the implementation of individual components.

Many design decisions are influenced by the familiarity of the resources tasked with the design. Most people would not design something that they had no familiarity with, unless compelled by requirements. Many design decisions are influenced by the designer’s understanding of non-functional constraints and requirements. Many design decisions are influenced by the availability of tools and resources to construct the software.

If you do not explicitly set guiding principles for a design exercise, these types of influences are hard to mitigate, and can lead to unexpected consequences. So before you “make” decisions, define the decisions, put them in an appropriate sequence, look for themes or principles that emerge, and then promote the principles to the front of the list. Start making decisions.

When developing requirements for a business process in which there are valid process variants, one usually describes the process variants as a behavior. When modeling these variants, it is useful to consider each aspect of a process that has variants, and isolate unique behaviors based on some decision framework. Both the distinct list of behaviors (behavioral taxonomy) and the attributes driving the decision framwork (driver mapping) are important to the model.

The list of behaviors is important, because the words that identify each behavior become important words in the language used to describe your business process. When you talk about these behaviors, you all (technicians and subject matter experts) can use the same unambiguous terminology to describe the process.

Sometimes in the business process documentation, the language is about the steps and the business rules that govern each step. At a higher level of abstraction, we benefit from aggregating these business rules into patterns, or behaviors that have some cohesion around a small number of attributes or facts. When we observe these patterns, we can simplify the language around the business process, by naming the distinct patterns as specific behaviors, and identifying them with a business driver as observed in the attributes.

When we isolate and name the patterns as specific behaviors, we also can understand the data elements or attributes and values that drive the decision framework. This mapping of data elements and values to select a behavior is also part of the requirements, as it is important to ensure that all valid values for each attribute are considered in the behavior selection.

More complex processes may have several different aspects that are governed by distinct behavioral taxonomies, and isolating these taxonomies from each other is important. Sometimes when we try to render a single behavioral taxonomy that governs a process, and find that we cannot easily recognize the behaviors, we actually have a more complex case, where there are nested behavior variants, or we have non-correlated (independent) behaviors governing several aspects of a process. In these cases, if we isolate the individual lists or taxonomies of behaviors, then review against each other to determine whether relationships exist between taxonomies. Those relations can be classified as governing hierarchies (where available selections in one taxonomy are limited by the selection in another “governing” taxonomy.), or incidental constraining relations (where as it happens, the selection of a behavior in one taxonomy, either requires or invalidates one or more behaviors in other taxonomies, but those constraints are not imposed exclusively in any one direction between two taxonomies)

Clearly identifying the distinct behaviors of the business process, and the data elements or attributes that can be used to select each behavior supports a good modeling practice.

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.