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…
Capability Exploration
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,…
Vendor Capability 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…
Planning Sequencing Elaboration
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.…
Units of Work
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…
Units of Value
Planning a software development project is difficult. There are the typical issues: the changing face of technology, abstractions and generalizations, process maturity and resource competency. But none of this gets to the heart of why planning a software development project is difficult: because all of these things assume that the customer actually knows what they…
Emergent Requirements
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…
Leading by Naming
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…
Leading by Asking
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…
Design Assumptions
Pragmatism – design assumptions are about pragmatism. Pragmatism is the easiest path to good enough. If I already have tools available that will allow me to do the job "good enough", why would I go buy and learn new tools? If I already have a team that supports 5 applications written in Java, why would…