Skip to main content

Strategic and Utility Projects

There are two kinds of systems/projects and the differentiating factor is competitive advantage.
One is called Strategic and the other is called Utility.

• An example of utility project is a ‘payroll application system’.
• In utility projects/systems, the focus is to keep the cost low and avoid disaster.
• Risk: is a risk of commission –doing it wrong.
• Use utility packages and reduce the cost ( compared to building customized systems; remember peoplesoft)

• The other kind of system is strategic in nature. It can be any system that provides the competitive advantage to your business.
• In strategic systems, speed and innovation are more important and cost is a lesser consideration.
• Risk is the risk of omission- missing doing it.
• To attain the differentiating factor, follow shorter iterations, use cross functional and high capability teams.

When I heard Martin Fowler talk about this ( December 2010 Chennai, India), following thoughts came to my mind.

# Strategic projects, by their very definition don’t allow us to be focused only on resource utilization and capacity utilization.  These do matter, but we won't be dead if we go above planned limits on these, but can consider ourselves dead if we miss the target.
# This strategic vs utility categorization helps when companies need to do their portfolio planning and assign their limited resources.
# This division need not be a strict dichotomy, since for sure, there may be more categories of projects people can come up with. But if we strictly use the word 'competitive advantage' to define 'strategic projects', and be honest and can make people see the advantages of this approach (without allowing politics to color our decision making), then i am sure we can just do with these two categories.
# If a project is identified as Utility, then the company need not spend the same kind of resources on it like it were a strategic project. Where ever it is possible, company can get to save money by aligning their process in synch with the process definition of commercial off the shelf software (COTS).
# Projects can start as strategic and then become utility or vice versa. this happens when the project no longer provides any competitive advantage.


Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …