Articles by Rich

In my last post about Estimation Purposes – I spent a little time talking about the reason that our customer might want to estimate, and how estimation informs our conversation with the customer.

But the reason for estimation goes beyond the customer, and into our own management and leadership.

Listening to the #NoEstimates conversations that have been going on, I realized that most were focused on estimation only in the context of a project.  As if the sole purpose of the estimate is to determine how much the project will cost, and how quickly it can be done.

On another post that I am working on I talk about management and leadership activities, things that are “meta” to the project and meta to the people who are doing the work.  Forecasting.  One of the things that managers are responsible for are forecasts.  They need to compare their incoming budget forecast with their resource forecast.  They need to plan when they onboard and release contract employees, and how leadership will be assigned to projects.  They need to forecast how resources will be deployed so that all projects will have access to the skills required to get to done.

Estimates give them the ability to look ahead, to forecast, to plan, to lead.Continue Reading

Caution: Rant Ahead!

E-mail chains.

Ken sends a note to Carole, his boss: “I need to know what systems our teams use for client servicing activities, can you help”? Nothing wrong with asking for information. Unless you’re asking people who don’t have a reason to know about what you’re asking.

Carole forwards the note to Joe, a project analyst: “Hey Joe, can you help Ken with this?” PUNT! Carole is newer to the group, and not as familiar with what systems are used. She thinks that Joe who has done numerous projects with systems may have some information.Continue Reading

So in prior posts about IT Strategy (The Goal of IT, Enterprise Application Value) I have talked about IT’s “Outward Facing Strategy”. So this post will be more about what are we doing to help ourselves deliver against our outward facing strategy.

At the top level of our Internal IT Strategy is our values: What we believe is important. What we value is the essence of our belief system.Continue Reading

A recent exercise at the job around improving the accuracy of estimate for software delivery projects caused me to have a minor epiphany!

When doing agile software delivery, we generally get value from having more information sooner. But this plays differently in managing the backlog.

We have been working on writing basic stories for all the ideas in our backlog, and producing T-Shirt size + Confidence estimates on each story. The challenge, is to scope a release and commit to a schedule with greater precision. Our customer (and management) would like us to estimate with greater precision, to match the estimates that are performed at each stage-gate in our non-agile software delivery life cycle.

The problem is, that our backlog (“Chinese menu”) estimates do not contemplate the state of the code base at the beginning of the release. We do this intentionally, so that the customer (product owner) can move stories backward and forward in the sequence without considering any cost or schedule optimization that could be had if we delivered in some sequence other than VALUE OPTIMAL.Continue Reading

This is a continuation of the last post, The Goal of IT where I tried to separate out how IT as a business function contributes to the goal of a company. Most of my experience is in Enterprise IT – that is IT is a function of a larger business enterprise, not specifically creating IT products or services for sale.

Enterprise IT is typically regarded as a cost center, not a revenue center. We are a support service to the larger business model, not dissimilar to facilities, legal, or human resources.

In the last post, I claim that IT exists to support the goals of the larger business enterprise, which are ultimately, to make money. The way IT accomplishes this is by delivering application capabilities, period. Working application capabilities that are used by business people, to increase their throughput, reduce their operating expense.

The business gets value from application capabilities in the same way a manufacturing plant gets value from machine tools, it uses them to increase the throughput of the manufacturing process. If a machine is not used, it does not increase throughput. The same is true for software – if it is not used, it cannot add value. Continue Reading

I recently re-read a book called “The Goal” by Eliyahu Goldratt. I had read it years ago, and at the time it had resonated deeply in my mind. Sometimes it is beneficial to review concepts that resonate.

For years, I have been working in the application development domain within IT. Most of my views on IT are application software centric. I have held these views because it seems natural to me that without some application, all of the physical hardware and infrastructure software and tools don’t really deliver any value. Like principals of engineering, without application, they aren’t terribly useful.

So if we retain that as a principle, it leads us to imply that the purpose of hardware and infrastructure and tools is to support software applications. It does that in two main ways:

1) making application software capabilities available to the user
2) making application software capabilities easier (faster, less costly) to create and maintain

Those are the two main goals of IT infra. If you have another, I am open to see how it plays. If you agree with me, then I believe that infrastructure goals are completely subordinate to application software goals.Continue Reading