Business process documentation often reflects decisions that are made during the process that affect subsequent steps in the process. Somtimes the decision can affect the necessity of a step or the outcome of a step. When decisions are made during the process that affect subsequent steps, the result of that decision becomes a data element…
Uncategorized
Undocumented, Unrecognized Process
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…
Impact of Design
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…
Fallacy of the PMO
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…
Design Decisions
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…
Behavioral Taxonomy
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…
Prioritizing Requirements
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.…