February 2011 – In Search Of

Quotables

Posted on February 28, 2011Leave a comment

Over my career I have heard or said some amusing things…

“Fix like a car, or fix like a cat?” – John Merenkov, M.D.

When you fix a car you restore normal operation. When you fix a cat, you
prevent the “problem” from recurring. This may be accomplished by brutally
removing the source of the problem.

“You can lead a horse to water, but you may not be able to hold his face
under the surface.” -me

Sometimes people are stubborn, but drowning them may prove more difficult
than originally thought.

“If you show a man fire, he will be warm for a little while, but if you
light him on fire, he will be warm for the rest of his life.” –
unattributed

Sometime your goal is not the comfort of your team, but to induce a sense
of urgency at the risk of burning them out.

Objective perspective

Posted on February 24, 2011Leave a comment

Sometimes things that appear obvious when viewed from a distance are much
less so up close. Organizations and situations appear completely from the
inside than from the outside.

In order to become objective, one may need to gain some perspective. This
may require viewing from different sides and distances. It may require
putting yourself in someone else’s place.
You cannot consider your view as objective, until you have taken the time
to reconcile other points of view. When you have looked at all faces of
the situation that you can see, and your assessment is still valid then you
are approaching objectivity.

In this same way, don’t assume that others see things from your
perspective. When they don’t appear to agree with you, it may seem like
they are obstinate. They may simply have knowledge, experience, or insight
that allows them to see things that are hidden from your view. Start with
that assumption, and you may learn from them.

100% SLA Requirements

Posted on February 10, 2011Leave a comment

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 people are imperfect, and that all man made products
are imperfect. Computer hardware and software are imperfect, whether we
built it or bought it matters not. The 100% SLA is not a feasible
requirement because it assumes perfection that cannot be achieved.

Sometimes failures come because things outside a process change without our
knowledge. These events can happen without our awareness and the faster we
detect them, the faster we resolve.

If the customer needs to ensure that his business process completes 100% of
the time, then he should define requirements to “detect and inform” process
failures, to feed a backstop process that corrects them.

If these failures are frequent, he should perform root cause analysis to
create new requirements to “harden” the process against future failures of
the same root cause.

This model provides a path to correct and another to improve. These paths
lead to maturity and quality, a 100% SLA is a path to disappointment and
frustration.

Direction, Trust, Feedback and Support

Posted on February 9, 2011Leave a comment

Most of us need these three things in some measure to be successful.
Leaders may need less than others, but also need to remember that those
that they are leading need these more than they do.

Most leaders will pick directions when none are provided, accept
forgiveness rather than permission, assume things are good based on
results, and ask for what is needful, network to build support for
initiatives and goals.

As leaders, we need to remember that those we are leading often need fairly
explicit direction, and permission before starting. They need to feel
trusted, and supported in order to accept responsibility.

We need to gauge how much of these things our team members need to be
comfortable, so that we can know when we are asking them to step out of
their comfort zone.

As leaders we may be graded by our customer, sponsor, and manager based on
our results, but we are graded by our teams according to how we have met
their individual needs for direction, trust, feedback, and support.

Impact Owners

Posted on February 8, 2011Leave a comment

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, but end up making commitments that you cannot deliver against.
You select a technology pattern that is common in the industry, and easy to
find resources to staff, but your organization fumbles the implementation
of the required infrastructure, delaying your project, and reducing the
perceived quality of your application.

These are examples of situations where your intentions did not match the
outcomes. How easily do you own the impact? How much easier is it to own
your intentions and assign the impact to others? How easy is it to blame
my colleague for being “difficult” to work with? To blame the project team
for the delivery failure? To blame the infrastructure team for your app
problems?

Leadership demands the trust of those you are leading. Whether you are
leading your reporting staff, a project team, or some other organization or
group, trust is required. Whether leading from a position of authority,
influence, knowledge, or savvy, trust is required. Leadership without
trust is a form of tyranny.

Leaders can be trusted when they are willing to own the impact along with
their intentions.

Specificity

Posted on February 4, 2011Leave a comment

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 is experiencing some
issue, but no assessment of the impact of that issue or options to overcome
it?

In each of these examples there are some questions that recipients ask
themselves:

1) Why should I care? – the sender has not given me enough information to
assess the priority or urgency of a response.

2) What should I do? – the sender has not asked for any specific response.
How can I know that any response that I make will improve the situation.

3) Who is responsible? – especially if there are multiple recipients of the
communication, will someone else “take” this one?

The sender has (consciously or unconsciously) assigned all responsibility
to the recipient(s) for understanding the nature, impact priority, urgency,
cause, resolution. He has assigned all decision rights, and responsibility
for communication as well. This creates a “hot potato” where by “touching”
it I risk getting burned.

So when sending communications make sure you “speak” with enough speficity
to allow recipients to respond with confidence. Review your outbound
communication as if you were the recipient. What questions would this
raise for you? How would you respond?

Sooner

Posted on February 3, 2011Leave a comment

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.

Vendor Candidates

Posted on February 3, 2011Leave a comment

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 vendor's capacity to add capabilities to their software product.
2b) the alignment of your business function with the vendor's target market.

These correlate to:

1) how little benefit you will likely realize during initial implementation.
2) how little benefit you will likely get from future releases of software product.

These are compared to:

1) how much it will cost you to purchase and implement the software.
2) how much it will cost you to maintain and upgrade the software over the lifetime of the application.

If you need to customize the product, or you need to pay the vendor extra to customize or develop capabilities so that you can accept the product, these change the cost/benefit ratio as well. A bird in the hand is worth 2 years worth of customization – by either you or the vendor.

If the product must be integrated with other systems in use at your company, those costs must be considered, as well as integration testing whenever either end of the integration changes.

In either case, whether you realize it or not, you are entering a partnership with the vendor, if the vendor doesn't act like a good partner, they probably won't be. Their corporate issues can become detrimental to your product implementation. Their staff choices can have tremendous impact on your ability to get your project done. Their vision for their product can easily move away from your companies goals. The cost of replacing the customized or integrated software will be higher than otherwise, and in all likelihood, the value delivery will be lower than expected.

Choose wisely, it pays to be careful, when making such decisions.

Fidelity

Posted on February 1, 2011Leave a comment

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 detail in the plan. Only document the
actual tasks representing the real work in detail, rather than fictitious
tasks that will be replaced with real tasks later.

The shorter the time span of a task, the nearer our ability to prove the
fidelity of the estimate.

in order to realize this ability, I also need to measure frequently,p
relative to the mean duration of tasks in the plan. That is, I should
measure every time a few tasks are completed, so that any propensity toward
fiction in the estimates can be observed and biased.

Reaction time breeds agility. The shorter the project, the less time to
adjust. The less time to adjust, the more frequent the measurement must
be. The more frequent the measurement, the smaller the mean task duration
must be.

How you plan determines how quickly you will be able to react as fiction
leaks out of your plan.