project – In Search Of

The Other Side of Product Investment

Posted on April 29, 2014Leave a comment

If you are a project manager that does software projects, you deal with the “top side” of product investment all the time. Whether your teams are running agile like scrum or kanban, or whether they are running a phase-gated cycle (waterfall), you are focused on the decisions about organizing the investment into packages for release or deployment. You are running the factory which takes requirements in one end and (hopefully) spits working features out the other. You are working with the analysts or product people to ensure that there are enough requirements, stories, or ideas “ready to start” to keep the team occupied.

But what about the other side of product investment? We often talk about return on investment or ROI, but most organizations only use an ROI project to justify the investment. Some will go as far as to attempt to measure “hard” ROI numbers, but frankly even that is missing half the boat because it is hard to measure the impact of software capability on your organizations top line or bottom line. Without a body count, the best we can do is to infer the correlation of software capabilities to a movement in profitability and assume that the relationship is causal. When it comes to softer benefits like risk reduction, customer satisfaction, or employee retention, there is no reasonable way to measure “hard” ROI dollars.Continue Reading

Project vs. Product

Posted on November 20, 2013Leave a comment

Continuing down the path of understanding the differences between contemplation of project vs product as the center of our software universe.

Here are a few pithy aphorisms:

The resources expended during a project are the cost of the product created, not its value.Continue Reading

Product Centered Worldview

Posted on November 12, 2013Leave a comment

Agile thinkers focus on the product – and how we are intentionally adding value to a “software asset” and potentially how we manage our “portfolio” of software assets. Phase-Gated Delivery (some people call it waterfall) patterns allow us to “optimize” the work against the constraints – but do not allow us to optimize the value delivery in time. In fact, they push ALL the value delivery to the very end of the cycle. But in theory, because we can optimize the projects by minimizing the schedule and cost against a constant value output – the value can be had for less investment. Problems arise when – the actual value is realized over time (meaning the sooner the customer has access to a software capability, the sooner his actual costs go down or his profits go up).Continue Reading

Proper Task Length

Posted on July 2, 2013Leave a comment

Glen Alleman in his post How Long Should Tasks Be gets to the heart of an important issue. When planning, how long can you wait before you know that you are late.

In principle, it works like this – you don’t know you are late until you fail to complete a task on schedule. How late you are depends on the remaining work in the late task. How long can you wait to determine that a task is behind schedule? That depends on where you are on the project timeline and how much “margin” is remaining in the plan.

In practice there are other dependencies. Measurement frequency is important. The more frequently you measure progress against the plan, the smaller tasks increments you will naturally prefer. You want to see progress at every measurement cycle.Continue Reading

The Slide

Posted on January 31, 2013Leave a comment

Did ya ever work on a project that seemed like the schedule was too aggressive? Where the team had to constantly fight to stay on schedule, and to keep moving forward? Where things maybe got behind and we piled more resources on to catch up? Where things felt bad, but we kept on fighting until…

…it was too late. Like in baseball, when the only way get on base is to slide in? Like in football, when you just need that one more yard, and you then turn it over?

The thing is, software development isn’t a sport. We don’t have an opposing team. We don’t have a team owner or coach. Software development is a business activity. It is an activity of manufacturing, of logistics, of research and development and of analysis.

The enemy is risk. In order to defeat risk, we have to understand where risk comes from, and we have to understand how to retire it. Risk is tricky because it costs you little (or nothing) to carry it, but much to quantify, even more to retire it, and potentially even more when it is realized.Continue Reading

Progressive Elaboration

Posted on July 10, 2012Leave a comment

Progressive elaboration is one technique that can be applied to virtually any aspect of software development. In reality it is a simple analysis technique which revolves around the maxim: start with what you know.

In agile software development, we apply this to several activities: requirements, design, and planning.

Progressive elaboration starts with the notion, that you cannot know enough about a software system to get to “done”, before you start. Progressive elaboration is sort of a continuous bootstrap process for knowledge.

While agile proponents also talk about how they embrace change, that is not what progressive elaboration is for. Progressive elaboration is a means to get started before you know enough to get to done. It is a means to prevent knowledge gaps from impeding progress. It is a means of driving out information through completing work, rather than by theoretical analysis.Continue Reading

Starting Green

Posted on March 20, 20121 Comment

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.

Project Pork Prevention

Posted on January 3, 2012Leave a comment

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.Continue Reading

A Definition of Done

Posted on September 7, 2011Leave a comment

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.

A Template That Inspires Innovation

Posted on March 6, 2011Leave a comment

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.