From start to end: September 2006

VIDEO: Excessive Jargon

Here's a short video that parodies what happens when you use too much jargon. No one understands anything!

Disaster Recovery, Requirements Management & Alignment resources

Here are some resources I've come across that may help you.

Requirements management
Best Practices for Enhancing Project Success is a recorded webinar that you can watch at your leisure.

More than 70 percent of software project failures can be traced to poor requirements management. The root cause: the gap between what the business team wants, and what is communicated to IT for delivery back to the business.

Disaster Recovery
CIOs lack confidence in their DR plans

IT execs are insecure about their disaster recovery plans.

That's according to a new survey by Rochester, N.Y.-based Harris Interactive Inc. that reported 39% of executives polled gave their plans a letter grade of C or worse, revealing a troubling lack of confidence in disaster readiness.

The survey results also indicated that this lack of confidence in disaster recovery planning is growing. A similar survey conducted in 2004 found that only 24% of executives gave their plans poor grades.

ALL-IN-ONE GUIDES: Disaster Recovery

This All-in-One Guide will get you on the path to a good, solid DR plan and show you what you need to do to maintain it. It starts you off with DR planning and design with understanding recovery capabilities and tools, and then takes you right through to DR implementation, security and testing.

Alignment
IT/Business Alignment

The IT/business alignment topics page provides CIOs and IT management with up-to-date information and resources on budgeting, IT governance, IT spending, leadership and strategy, and Return On Investment / Total Cost of Ownership.

On September 13, I had the opportunity to attend a Power Within speaking engagement being held in Toronto. The event looked very promising with speakers such as Micheal Eisner, Sir Richard Branson and Tim Sanders taking part. You can see the full details about the session here.

Micheal Eisner's speech on management was very interesting. He spoke about how Disney used inside-the-box thinking to spur creativity and innovation for their entertainment initiatives. This may sound contrary to the outside-the-box paradigm that is prevalent now, but what Mr. Eisner meant was that for a given project you must understand the size of the box (e.g., amount of resources and money you will devote to it) and innovate, manage and be creative within those confines. He used clips from movies such as Who Framed Roger Rabbit, The Lion King, Outrageous Fortune and Pirates of the Caribbean - Dead Man's Chest to illustrate his points. The complexity concerning things one would not give much thought to was astounding. The example shown was the shading on Roger Rabbit's character while a overhead light swung back and forth (the picture is courtesy of Disney via Google.) This was something that was extremely challenging to perform at that time.
Tim Sanders was a former motivational coach at Yahoo! Mr. Sanders was an engaging speaker and talked about what he termed the, "likability factor." The basic premise is that people who are more likable are more prone to succeed versus an equally competent but less likable individual. He reasoning (backed up by lots of research) was as follows:

People want to work with individuals they like.
People will be more willing to assist someone they like. Such as give them information that will provide an advantage in a negotiation or a business deal.
When choosing between two identical proposals, the one from the individual you like more will generally win.

Mr. Sanders pyramid of likability was as follows (I've stated it upside down):

Friendliness - Make people feel welcome and comfortable.
Relevance - Validate commonalities between yourself and others.
Empathy - Understand feelings are facts. Be a good listener. Don't judge or try to fix the problems.
Realness - (At the top of the pyramid) be genuine. When someone is talking to you, give them your complete attention.

The keynote of the event was Sir Richard Branson. I must admit that this part of the event was a little of a letdown. It was run as an interview session with questions from the audience. Mr. Branson has significant charisma, however I did feel he rambled and didn't necessarily answer questions the audience's questions.

The event itself was good on a whole. If you can find a session keynoted by someone like Bill Clinton, I'd definitely say to check it out!

Webinar: Harnessing Emerging Technologies

Here's an interesting webinar, How to Harness Emerging Technologies to Boost the Bottom Line, from Ziff Davis.

Why do innovative companies find benefits from emerging technologies that others overlook? How do their IT teams use new technologies to create products and services and add value for customers? How do they help drive business innovation and keep competitors at bay?

View it on-demand here.

1, 2, 3 align your projects!

What are the steps involved in aligning projects to a strategy?

There are many different projects that a company can undertake. The first step is to create a list and make sure that everyone understands what each project is about.
Determine the criteria you will use. Your criteria should match your strategy and be representative of the direction you want your company to follow. For example, if you want to be a low cost provider, one of your potential criteria could be, "that a project should reduce the costs of service or increase the efficiency of providing service using your call centre."
Some things are more important than others. Weight your criteria.
Let the project sponsors individually score the importance of the projects using your criteria. Tabulate the results to reduce bias that the sponsors may have towards a one project or another. Projects that score high align more closely with your company's strategy and direction.
Establish high-med-low groups of projects.
The groupings and individual rankings form a basis for prioritizing.

By the end of this process you will have determined objectively which projects align better with your overall strategy and goals. Note that there are factors other than strategic fit that determine which projects will ultimately be undertaken (e.g., compliance, ROI.)

Webinar: Getting Agile with Your Projects

There's an upcoming webinar that maybe of interest.

Wednesday, September 27, 2006, 2:00 pm Eastern, 11:00 am PacificTap into the power of Agile software development with Dr. Alistair Cockburn, one of the forefathers of the Agile movement, and learn important risk-reducing strategies for your projects. Developing executable code that offers business value is the heart of project delivery, and using tools that support the collaboration and distillation of business rules and requirements into automated test suites is imperative. Fergal McGovern, originator of Optimal Trace, the leading Requirements Definition and Management Tool, will outline how a structured approach accelerates successful project delivery.

Enroll here!

Video: Cubicle wars

Sometimes you need a laugh. Courtesy of Windward Reports and Youtube.

Project prioritization goals

Continuing on from my post, Why prioritize projects?, prioritization is important because,

It provides focus to the more important initiatives. Companys can concentrate on what really matters to them and not be distracted by the latest fad.
Money, time and people are scarce resources. Proper management and effective use of these resources can only benefit a company.
In order to prioritize projects you much be able to compare them against each other objectively. This apples to apples comparison removes bias from decision-making.
Clear direction and visibility to everyone in the company, not just the main decision-makers. Everyone is on the same page. We all know what can happen when things are not clear.

Stop 'gathering' IT requirements

There's a post on Techrepublic titled, Project Managers: Stop "gathering" IT requirements.' It's an interesting read.

And when I ask why projects get bad requirements, the answers are, "Users won't tell us what they want," or "We don't ask good questions," or "What they told us they wanted turned out not to be what they really wanted." But I think that the problem is more subtle than any of those answers.

The author, Paul Glen's, point is that, "project managers should negotiate requirements among the stakeholders." My comments on the article are as follows:

In order to negotiate well, a project manager really has to understand the nature of the project and client ask. If the project manager doesn't understand the ask (e.g., isn't familiar with the business), a strong supporting cast is needed to keep everything real. Are you more confident when you know your project manager has lead projects similar to the one you are on or is very familiar with the industry?
Requirement 'gathering' means collecting requirements, however, a business analyst is paid to understand them, derive meaning from them and then communicate the underlying business objectives. To me, this is the core competency of the role. The article does not really talk about this. You do not need a business analyst to order take.
The following comment from the article seems a bit over the top, "We should think of a set of requirements as being like a multilateral treaty among a group of nations." I understand the need to have clear understanding and expectations, but this sounds like something people do when they don't trust each other.

I think, if anything, this accentuates the need to have a strong capable business analyst.

Why prioritize projects?

Projects are initiated to capitalize on opportunities (the Chinese character for crisis is the same as opportunity I've been told) that a company faces. However, not all projects are created equal.

To quote George Orwell's Animal Farm, "All animals are created equal, but some are more equal than others." Some projects are more beneficial than others.

Prioritizing projects is very much like managing investments. In fact, it is the same. How likely are you to perform due diligence before making an investment decision such as buying a bond?

You need to understand:

The anticipated returns
The potential risk
The timing of the returns

With this information you can perform a net-present value calculation to determine the value of one investment versus another. Combined with other factors such as your risk-tolerance and investment goals you'll choose the most appropriate ones for you. The purpose of all of this is to introduce objectivity into your decision-making.

Extending this principle to project prioritization means you should:

Understand how important a project is to you. How well does it align with your objectives?
Prioritize your projects early to allow for lead time for effective decision-making.
Introduce objectivity into your prioritization process. Just because someone yells loudly does not mean his project is the most important.

Do not take the position that:

Prioritized projects must be executed sequentially. Some minor projects are dependencies for others. Some projects are easy to slot into non-peak times.
You only prioritize when you need to make a decision. The earlier you prioritize, the more potential problems you can avoid before they become critical.

It's a bigger world

We've all encountered situations where difficult decisions had to be made concerning a project.

Should we continue?
What features do we need to pare back?
Do we need more money?
Are we missing needed skill sets?

These decisions are normal things that occur within any project. However, the ramifications for handling them may impact things outside of the project in question. What if an increased budget means another initiative has to go unfunded? Or perhaps the added resources need to be taken from another project's resource pool?

Instead of managing a specific project, decisions have implications across a collection of inter-dependent projects. The management of the collection is termed program management. The purpose of program management is to use the scarce resources and funds available to orchestrate projects to deliver maximum benefit. If you've taken basic economic theory you may remember the definition of scarcity.

The basic economic problem which arises from people having unlimited wants while there are and always will be limited resources. Because of scarcity, various economic decisions must be made to allocate resources efficiently.(Investopedia.com)

It's true, you just can't do everything!

One thing I was told very early about projects is that, "Projects end. If it doesn't, then it's not a project." If that's true, then programs, being a collection of projects, end as well.

But we also know that businesses constantly evolve. Their products and services are impacted by innovation and change caused by internal or external sources. If you will, the portfolio of service offerings evolves continuously. To me, I view this evolution as portfolio management. Clearly, this terminology evolved from finance however, it is also applicable to the management of a company's set of offerings and how they are transformed over the passage of time.

The art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk vs. performance.

Expanding further upon the concept of program-wide decision-making is the notion that decisions across a portfolio can have implications in many of the different programs within it. A portfolio is governed by the higher level strategic goals of a company whereas program decisions are governed by lower level objectives.

For example, suppose one of your strategies is to become a low-cost provider for a given product. Your product development team may look at projects that reduce the cost of the materials used while your service team may reduce the number of agents who handle customer inquiries and beef up the self-help sections of your website. Together, these two programs work towards meeting your strategy.