Published: May 27 2009, 01:17 PM | no comments
by Steve Romero

I recently responded to a blog post that delved into our motives when making decisions and getting things done. The post included the following interesting dilemma, "One person's influence is another person's politics." This is SO true, but only in the absence of the constructs and conventions capable of exposing the true nature or our behavior.

Consider the definition of "play politics" - which I found listed as an Idiom at Dictionary.com when I looked up the word politics:

- To deal with people in an opportunistic, manipulative, or devious way, as for job advancement.

I am sure countless examples of this come immediately to mind. I contend the pervasiveness of this behavior is due to (and please don't laugh), the lack of Governance. That's right. I am saying Governance deters politics.

Consider the simplest definition of governance: the processes and relationships that lead to reasoned decision-making. I use this basic definition to convince all organizations that if they are making decisions, they have governance. I simply point out that their governance is comprised primarily of relationships (people) and non-existent, ad-hoc or chaotic processes.

When organizations lack adequate governance, especially when it comes to projects and programs, they rely almost completely on people (and their associated relationships) to make decisions. This situation does little to prevent people from playing politics and in many cases, actually enables it due to the lack of the processes and associated controls and measures that ensure "reasoned and rational" decision-making.

In such cases anyone can argue either side (influence vs. playing politics) and there is little in place to reconcile differences in perception. And when somebody is accused of playing politics, they can easily justify their political behavior with the argument of "the ends justifying the means."

Sound governance will not completely eliminate this destructive behavior, but it goes a long way to inhibit and expose it.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: May 22 2009, 10:11 AM | no comments
by Steve Romero

In every presentation I deliver, I talk about value. Many of my recent posts have addressed the elusiveness of understanding and determining value in enterprises today. We don't know the value of our processes, our methodologies, and most regrettably, we don't know the value of our investments.

A recent IT Governance Institute (ITG) IT Governance Survey of 255 Non-IT Executives showed that Value Delivery was the leading motivator for implementing IT Governance in an Enterprise. (Value Delivery is one of the five principles of IT Governance, in addition to IT/Business Alignment, Managing Risk, Managing Resources and Managing Performance.) Before this survey, Risk Management had always been the #1 driver.

I am encouraged by this recent trend and thrilled that organizations recognize the importance of understanding the value technology delivers to an enterprise. But my delight is tempered by the difficult proposition of proving value. And this goes beyond proving the value of IT investments. I am asked how to prove the value of project management processes, of processes such as ITIL, and even of IT Governance processes themselves.

When folks ask me how to prove the value of any process I evangelize I tell them their very first step must be to determine how value is defined by whoever is paying for the process. It is only then that they will have any chance of knowing:

• if the process value can be determined using the given definition of value
• if the process has the potential to deliver this value
• if the process, once implemented, is delivering the value

This same approach must be applied when proving the value of investments. Simply replace the word "process" with the word "investment."

As long as an enterprise is able to define what value means to them, it is possible for them to establish the governance to determine the value of any process and more importantly, of any investment. I say "possible" because the severe lack of sound governance in many enterprises makes this valuation process quite difficult and elusive. Even so, we have to begin somewhere, and defining value is the right place to start.

Let me know how value is defined in your organization, and how you determine and prove the value of your processes and investments.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: May 20 2009, 09:19 AM | 3 Comment(s)
by Steve Romero

I just read a blog with this title on Aras' "How to Manage a Camel - Project Management and Recruitment site. http://projectcentric.co.uk/how_to_manage_a_camel/projectmanagement/guest-pm-blogger-whats-wrong-with-the-triple-constraint/. In summary, the premise of the post is that the three dimensions of the project management triple constraint (Time, Cost, Quality) are insufficient. The author suggests another factor, Benefits, should also be considered when making project decisions.

I like the idea that the author identified a fundamental drawback of the Triple Constraint Model and proposed a thoughtful solution. As noted in one of the replies to his post, there may be even more legs to this "stool," such as Risk.

Let's consider this for a moment...A five-legged stool? Can you see where I am going?

Though I agree the model is flawed, I don't agree that making it more complex is the answer. So in the hopes of keeping the model simple, I suggest the flaw lies in the legs themselves. I offer these 3 legs instead:

• Speed
• Value
• Performance (or maybe Quality - I need your help on this one)

For those of you who have attended my Metrics presentation, you've already heard my thoughts on the "classic" project management metrics: Time, Cost, Within Scope. I have contended for some time that they are outdated and insufficient in making sound project decisions. Here are my arguments:

Time - If you give a PM and the project team 12 months to complete a project, how long do you think it will take? I can just about guarantee it will take at least 12 months - if not more. The team will inevitably end up using all of the time they are allotted. They will establish a plan to complete the project in 12 months, and when things inevitably go wrong, they will likely miss the mark. Instead, replace this metric with:

Speed - I want to give my project teams the "must have date" and have their first response to be, "How can we beat that date?" They will respond in this manner because they know nothing contributes more to a project than getting it done! I read a Forrester report a few years ago citing schedule as the #1 factor in determining project success. Their research found that projects 50% over the original timeline almost always have zero chance of delivering their intended ROI. One of the 9 objectives I advocate for PMOs is to reduce project cycle times. I want projects completed as fast as possible.

Cost - Oh how I despise this factor. I think it is one of the worst metrics we have ever had for projects. Let me get right to my point, I don't care what a project costs. I only care about Value. Cost is a factor and metric we use because we are terrible at defining, estimating and determining value.

Value - I love this word. This is what I care about when it comes to all of my investments, the value they deliver. I have written a number of posts now on the subject and I believe organizations able to establish the governance processes to define, estimate and measure value make the best investment decisions. I understand how elusive valuation is but I am determined to advocate improved financial management systems. Imagine if you gave your project teams a new program and the first thing they considered was, "How do we get more value out of this investment?"  I want them to seek opportunities for additional investment capable of delivering exponential returns. These folks are close to the work, they are close to the customer, and we would be amazed at what they might suggest if we stop them from thinking, "We better not go over budget."

Within Scope - It does not matter to me that I stayed within scope. I care whether or not I am providing the customer with the performance necessary for them to meet their business needs. I admittedly struggled with the "Quality" leg of the stool. In the past, I was replacing "Within Project Scope" with "Performance." That change is pretty straightforward. I find it is not as easy to dismiss Quality because I actually list performance as a potential dimension of Quality in my Metrics Presentation. I also list: accuracy, conformance, completeness, reliability/durability, aesthetics, and serviceability. This one requires more reflection. In the meantime:

Performance - I like this leg of the stool because it gets directly to the customer of the product or service I am delivering. As I said above, am I delivering the performance they need to meet their business objectives? I am not going to hide behind the fact I may have met "their" requirements. Good project management processes ensure requirements reflect what is needed to meet business needs.

Using these dimensions, I believe we cover the two main inadequacies of the original 3-legged stool. First, any changes in benefits will be factored into Value, and risk can be addressed in all 3 dimensions.

Are there any factors you think won't be addressed by considering Speed, Value and Performance when making project decisions? Do you think my third leg should be Quality or Performance? Is Risk a 4^th leg? Let me know.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: May 13 2009, 08:14 AM | no comments
by Steve Romero

This blog post was inspired by Kristen Caretta of Search CIO @kcaretta who is writing an article about an organization's issues with legacy systems and she is looking for analysts, consultants to weigh in. I started writing her a response and thought it would make a good post. I have been writing on the topic of value with some frequency lately, so understanding the value of our systems and applications is timely.

Kristen's article will likely take on numerous dimensions. I suspect many will be tactical and operational because there are countless challenges associated with operating, maintaining, enhancing, integrating and ultimately retiring legacy systems. I focus largely on the strategic aspect of the problem - which is the very infrequent practice of Application Portfolio Management.

Application Portfolio Management (APM) attempts to use the lessons of financial portfolio management to measure and justify the financial benefits of each application in comparison to the costs of the application's maintenance and operations. This is incredibly important because large organizations have hundreds and even thousands of applications. APM provides the information needed to:

• Rationalize and prioritize applications
• Identify strategic and most critical applications
• Reduce or eliminate system redundancy
• Understand the value of program and projects requesting to invest in existing applications
• Free application maintenance dollars for higher-value uses

Many companies don't understand the value of their systems and applications. For most, the only time they consider the criticality of their applications (and by definition, the value) is during their annual Disaster Recovery or Business Continuity Planning. What they should be doing is using this essential insight to make daily decisions about their systems i.e. considering a project/program request that wants to invest in a legacy system with low value. Application Portfolio Management provides the insight necessary to determine if investing in a given system is a good business decision.

In addition to ensuring we know the value of these systems when considering project and program requests, application portfolio management identifies the low-value systems we should target for retirement (especially considering they are likely consuming a disproportionate percentage of operations and maintenance costs due to their age).

Application Portfolio Management also helps to counter the contrary behaviors of some of our system metrics. When I worked in Computer Operations, we focused on our 99.99-whatever availability. That was the measure of our success. We did not care whether the application was used by 5000 people or 5! There were even times when we didn't even know who was using some of our systems so we unplugged the server and monitored the Call Desk - to see if anyone called!

So for me, the first step in dealing with the "issues of legacy systems" is to understand their value to the organization. Application Portfolio Management is a great governance process that enables us to do so.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: May 11 2009, 12:43 PM | no comments
by Steve Romero

I am sure all of you have written or reviewed Project and Program Business Cases. In addition to those you have personally encountered you have seen many more examples, templates and recommendations for business cases.

In my experience, the #1 purpose of the business case in most organizations is to get the project approved. I think this is a recipe for disaster because it potentially promotes the wrong behavior. If all I care about is getting my initiative approved, then I need only understand my organization well enough to provide me the insight into obtaining that approval. This may be no more than knowing:

• Who to ask or schmooze
• What to say - the buzzwords du jour
• How to say it - manipulating if not exploiting the project approval process

I've seen some organizations manage to rise above these practices by installing the processes and mechanisms to ensure projects are aligned with Enterprise strategy and pledge to realize a targeted ROI. Even organizations achieving these higher-level business case practices are subject to the frequent problem of underestimating the full scope and impact of the project, what is actually required for success, and how to truly determine if it is a good investment. This is even more problematic with technology projects. They may approve the new technology that has all the earmarks of being the right thing to do and find all-to-late they did not have an adequate understanding of the associated business aspects required for success.

So we need a business case that provides us the information necessary to raise the potential for success. Once again, I turn to the ValIT Framework from the IT Governance Institute for a superb list of attributes for a great project or program business case. They suggest the following content:

• The business benefits targeted, their alignment with business strategy - who in the business will be responsible for securing them
• The business changes needed to create additional value
• The investments needed to make the business changes
• The investments required to change or add new IT services and infrastructure
• The ongoing IT and business costs of operating in the changed way
• The risks inherent in the above, including any constraints or dependencies
• Who will be accountable for the successful creation of optimal value
• How the investment and value creation will be monitored throughout the economic life cycle, and the metrics to be used

I love this outline because it does not neglect the associated and peripheral business dimensions of the initiative (note the word "business" is used 6 times - the term "IT" is used only twice). They also use the word "value" 3 times and rightfully acknowledge the requisite business changes and business accountability for ensuring success. I believe this level of detail and insight would enable most Enterprises to:

• Ensure they are investing in the right things
• Ensure the program/project includes all of the activities required for success
• Reduce the intolerable number of project failures
• Accurately measure the value of the program/project
• Improve their investment decision-making process

What do you think of this business case outline? Let me know if you believe anything is missing or if you have anything to add.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share