100% SLA Requirements

Sometimes our customers fail to understand the complexity of modern technology. Our customer expects a system that NEVER fails to complete some critical process. The problem is that when that critical process reaches a certain level of complexity, and/or has a single point of failure this is not a feasible requirement. We all recognize that

Impact Owners

How well do you own the impact of your actions, decisions, and communications? How frequently does the impact of our actions, decisions, and communications not closely reflect our intentions? You intend to partner with someone, but you end up alienating them instead. You propose an aggressive schedule for a project to get people focused quickly,

Specificity

Have you ever received a communication that raised more questions than it answered? A defect report that doesn’t describe expected result, only that the feature is broken? A review of a draft document with a sweeping condemnation of the content, without example or recommendation of desired changes? A project status report indicating that the project

Sooner

We all know that nine women cannot make a baby in one month. When developing a project schedule, projected duration can be calculated as estimated effort divided by full time equivalent resources multiplied by some P or “rho” factor of productivity usually a fraction between six and eight tenths. According to this formula, given an

Vendor Candidates

When purchasing software for your business function, one must consider the following: The software vendor has two value propositions: 1) The capabilities already built in the software product.2) The vendor's capacity to add more capabilities over time. These values must be compared to: 1) the prioritized requirements of your business function.2a) your assessment of the

Fidelity

Fidelity is truth. In software projects we need to know how much “truth” is in the plan and how much “fiction” might be in the plan. We know that the more detailed the wbs, the greater probability that it is truth, rather than fiction. The exception to this involves documenting heuristic tasks and estimates in

Assumptions

Sometimes it’s really beneficial to get a team all on the same page before you start something. Starting a design initiative for a software project is a good time to do this. One good way to get consensus or at least to determine how far apart developers are ideologically, is to document the assumptions that

Sufficiency

Sufficiency is a word that we don’t use very frequently. It has a high correlation with enough. In lean management circles, anything more than enough is waste. So how much is enough? How good is good enough? How soon is soon enough? How clean is clean enough? How fast is fast enough? Often we reward

A missing product role

Every product needs a champion. Trouble is, in the enterprise application software space, sometimes this role is left unfilled. Lately it seems like the enterprise space is dominated by project/program methodology, more than software design methodology. When your customer is the product owner, the team does not have a champion to rally around. With all