In Search Of

One of the most useless project management conventions I have ever worked with is the status stoplight or RAG status. From a simplicity perspective, it is designed to convey a general state of the project. Green means things are "OK". Amber means things aren't that OK. Red means things are not OK at all. The convention is to get the attention of stakeholders when the status changes from green to amber to red. It is a beacon, or warning signal that something needs to change.

Read the rest of this post »

Why is it that the customer in corporate software projects seems to want to pack the scope of every project with capabilities of dubious value, in the same way that our congressional leaders try to pack important bills with "pork"? Why do organizational leaders try to take a well funded project or initiative and use it as a means of funding their personal management agenda? Because like congress, if they can construe their agenda as essential to the completion of some important project - they bring the business value (pork) home to their department. They can use the project as a vehicle to accomplish things that ensure that they get their bonus. These leaders act as though their incentives are more important than the overall health of the corporation - just like congressmen act as if their re-election is more important than the overall health of the nation.

Read the rest of this post »

In his Herding Cats blog, Glen Alleman, asks a very pertinent question. What is the definition of done? Well?

Done (Enterprise software delivery project) - when software capabilities have been delivered that support the business value proposition per the customer's business capability requirements.

In our agility, we recognize that requirements are clarified by "emerging information". That doesn't mean that they "change". When a requirement "changes", it is effectively a new requirement. We often experience a case where the business value proposition is inadequately defined at the outset of the project. In this case, it is necessary for this requirement to be clarified by emerging information.

We also recognize that there may be different paths to deliver different software capabilities that support a particular business value proposition. Chosing a different path or delivering different software capabilities that support the same value proposition does not mean the requirements have changed, more likely that we are responding to emerging information.

I like to break requirements into business capability requirements and software capability requirements.  Regardless of your project methodology you must contend with these facts:

Fact: Enterprise software projects are created to deliver some business value. The requirements should define both the value (business capabilities) and a path to deliver it (software capabilities). Requirements form the basis of the definition of done.

Assertion: If the business value does not change, there is not a new requirement.
Assertion: If during the delivery of the business value, we learn things about the domain, the technology, or the world external to the domain that alter the path to deliver the value - there is not a new requirement - but emergent information.
Assertion: How we manage the (the documentation of our understanding of) requirements is a method.

Fact: Some software projects are required to change course mid-stream. Sometimes the business value we initially intended to deliver is overturned by market pressure, financial impact, or a change in management or strategy.

Assertion: When the business value for a project changes, there is a new requirement.
Assertion: When the work done toward that value is abandoned, there is a loss.
Assertion: How we manage the (documentation and accounting for) change to requirements is a method.

--
Recognizing that there is a difference between allowing emerging information to clarify, influence, or stabilize the delivery of value and accounting for changes in the definition of the value stream for a project is key to understanding agile and how agile methods manage both cases.
--

In either case, the definition of done is when we have delivered working software capabilities that support the business value proposition(s) that have been "commissioned" by the customer.

After adopting a new design process philosophy, and implementing a trial project using it, a design anti-pattern has presented itself.

Document Driven Design - this anti-pattern is the practice of allowing whatever document template is mandated, drive the actual process or practice of design.

It is common in the enterprise space, especially post Sarbanes-Oxley where such documentation is as essential for passing regulatory audits as it is for constructing application systems. Sometimes enterprise management get confused as to which is the primary objective. While I haven't read the federal register to determine what actually is required, many organizations have followed the consulting firm model, and developed a documentation framework for software projects that is mandatory.

I would expect that organizations that are towards the higher end of the capability maturity model use templates that are reflective of their already mature process, but organizations that are more steeped in chaos may be tempted to produce document templates that are an amalgamation of several different processes, thinking that those responsible for authoring those documents will know how to complete them. I have seen that this is not the case, and it can cause the aforementioned anti-pattern, that is reflected in the following statement: Design is complete, when the document is done.

As I said, I realized this after trialing a new design philosophy. New philosophy has 5 steps - initiate, decide, articulate, analyze, review. Articulate is the step where the the first draft of formal design documentation is created. The team had done fairly well, following the requirements of the philosophy until this point, and when they got there, we tripped over the template. Boom! Instead of figuring out what needed to be articulated, we attempted to cram all of the decisions we had made into the existing template, and became confused and the result was frustration. We got to the review step, and questions and accusations were flying. I had a great deal if trouble figuring out what went wrong.

What was the problem? Template thinking trumps philosophy! Why? I suppose that this is an instance of transposition of the familiar.

Now I realize that I have a challenge - that to support our new design philosophy, I need to construct an "articulation template" that can inspire innovation and help the team with the remaining steps of analysis ( which in my philosophy is impact analysis) and review.

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 unlimited supply of resources, any
project could be done tomorrow.

Of course in real life, we don't usually have an unlimited supply of
resources. And there are costs of on boarding per resource, and
collaboration. So even if we did have unlimited supply, we probably would
fail some financial constraint in that staffing model.

But we need to look at the work itself to determine how many resources can
be employed concurrently to get work done in parallel. What real and
assumed dependencies require work to be done sequentially? What can
overlap to allow more resources to be productive at the same time? And
finally, what design decisions have we made that impose constraints on our
parallelism?

If sooner is important, then you may have to design this baby so that nine
women can make it in one month.

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 will guide your
design.

It is not really important how you document them, the purpose really
is to get the team to articulate and discuss and ultimately agree on
the values, methods, approaches, and ideas that will guide their
design (and ultimately their build process).

Laying out your assumptions before you try to make decisions could be
a great way to shortcut some of the inevitable disagreements caused by
unexposed differences in the religious beliefs held by software
developers. Software theology and design jihad go hand in hand.
Assimilating new members into a team, requires understanding their
religion, with a view to preventing heresy from creeping into your
designs, and ultimately your code base. Having to declare a jihad
against all things that violate layer isolation, or the normalization
in the conceptual domain model during the design review is a bad idea.
Better to get the differences out on the table early.

It also makes your documentation easier to read because the
assumptions need much less justification than the decisions you are
documenting, and frankly can get assimilated by new team members
faster. Most of the WTF's in the design review meeting are really
poorly documented assumptions that one or another team member trips
over.

Most likely, though, the exercise will trip over semantics, and when
when you get down to the core values of the team, and what is really
important, good people agree more than they disagree, and they will
feel good about the things they agree on, and they will have a sense
of starting well, rather than a subtle dread of the design review,
expecting the "Here we go again..." approach.

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 the emphasis on cost and schedule (customer) who is the champion
of good ideas, of consistency, of integrity, of quality?

The customer certainly feels entitled to these things, but as a
non-practitioner, cannot lead us into practices that yield them.

Technical architect? Solution architect? Product manager? I think that
all these roles are defined too narrowly, and vested with too little
authority. I am looking for a champion - who takes on all comers to ensure
that the best decisions are made for the long term value of the product.

Spent the weekend (really the last two weeks) preparing to engage some
business partners on a project whose plan got somewhat sideways.

Original estimates were smaller than really required. Requirements took
much longer to elicit because the business vision was not complete, nor
were all that participated invested in a vision.

There has been a lot of drama around this project, because business execs
felt deceived. While the project team felt like it had been
extraordinarily transparent.

Then someone said it. Business reality implied a fixed bid process. While
IT was working on a time and materials project.

It explains why business gets angry and hostile when we shed scope to meet
a date. Their reality is fixed bid.

Internal IT rarely does fixed bid estimates. There is no motivation. No
profit. We only ever bill what we spend. But what if we did? What would
we do with the profit?

Reality?