CIO Perspective on IT Project Management

Scalable Project Discipline

Should we classify projects by size and scale project discipline using size (cost / effort) as the meter for project discipline? I've seen that more often, since investment size (cost / effort) at risk warrants discipline to improve likelihood of success.

But how about situations when various size projects (including small ones) are critical to business success and either time or quality of the deliverable is the key business driver. Business critical projects are worthy of a disciplined method of delivery.

Or, should we ignore size, etc. and achieve a level of PMO maturity that operates at such an efficient level of productivity and project volume throughput that the project management discipline is optimal across the full portfolio?

What do you think? ...

... "there must be a dividing line between projects that are complex and critical enough to require a full, rigorous methodology, and those projects that are simple and routine enough to be managed with minimal project overhead. The question is: Where is that line? " ...

Via TechRepublic: Project size classification determines rigor

Project Risk Transparency

Transparency to projects and the types of risks they may or are encountering can build credibility with business stakeholders. Watch out for the most-frequently occurring for IT projects: cultural / organizational risks where managing the change is the key mitigation. ...

... "Gliedman breaks down IT risk factors into two categories: implementation and impact risks. " ...

Via Computerworld: Influence the Business

Goal Setting

Setting your annual goals and objectives? Consider fail fast, fail cheap. Is failure your goal? Go ahead. Take some risk. ...

... "It's not stupid to have a stated goal of starting several ventures that will fail, or asking three stupid questions a week ... " ...

Via Seth Godin: The goals you never hear

Risk Management is a Strength

Whether buying stocks or investing in projects, risks must be understood, accepted, and mitigated. However, no matter how many controls are in place, some risks (see below) are impossible to see. ...

... "Addressing risk, even in companies and stocks we like, is not a sign of weakness, but of strength. It's what every investor should do when considering buying a stock. Satyam is a terrible, disappointing situation. Despite unease about management, it seems to me the full extent of the ugly truth would have been very difficult, if not impossible, to see ahead of time. But let's not give up on the quest for truth, even while remaining aware that sometimes we just can't foresee certain outcomes. " ...

Via Motley Fool: Satyam

Risk Analysis for Projects

Project Quality Assessment

An enterprise can assess its own quality and remain objective. There's thinking to the contrary. ...

... "Some quality functions within such organisations are genuinely trying to promote good practice. However, this is rare, in my experience. " ...

Via ComputerWeekly: Regulations for IT

Project Benefits Realization with Compensation Escrow

There's no doubt that Wall Street risk, returns, and accountability got out of whack. Since most investments, whether IT or other, are founded on the principle of ROI, how about using this escrow account / variable compensation approach until project benefits are realized ? ...

... "One idea is creating escrow accounts at each firm made up of, say, one-third of each year’s allocated compensation, which would be distributed to employees over the next three years - after the account is reduced by losses resulting from poor trades or deals ... " ...

Via New York Times: Risk and Wall Street Reward

Project Strike Force

Proposed bill will legislate identification and remediation of risky federal IT projects using a strike force. ...

... "S. 3384 also would establish an IT Strike Force (a group of information technology experts) overseen by the Office of Management and Budget (OMB) to respond to problems with individual IT projects. " ...

Via ZDNet: IT project failures bill

Collaborative Sustainability

SAP takes a collaborative approach to developing its strategies for sustainability, as it publishes its first update on the topic. ...

... "The first challenge in preparing this report was to decide what exactly to report on. It is not so obvious for a software company on the basis of risk alone. But once we started to engage with stakeholders over the past 18 months or so it became really clear that what our stakeholders are most interested in is the solutions SAP can provide to other businesses to become more sustainable. " ...

Via SAP Sustainability Blog: First Report

Project Impact from Credit Market Turmoil

IT projects in jeopardy of cancellation or on-hold status change? Creative financing could be an option depending on the scale of your implementation partner. ...

... "IBM has a large financial services group and it has the capital to help finance IT enterprise projects. " ...

Via ZDNet: IBM financing

Strategic Risks

Want to see risk from the board of directors' perspective? See this list of strategic risks so you can understand the mindset of those folks providing enterprise
oversight and making investment decisions. ...

... "Investment risk relates to the ability to manage business technology spending in a business environment in which capital is scarce and technologies are volatile, expensive and not easily understood. " ...

Via Baseline: Managing Risk from Board Perspective

Manage Uncertainty with Liquid Plans

Early Controls Increase Project Efficiency

Build in a brief compliance review early in an IT project to avoid costly rework later in the execution phase. ...

... "As stakeholders in the management of risk, when corporate legal departments provide their input in advance, i.e., during the design phase of an IT project, the resulting controls can be most cost-effectively designed and deployed. " ...

Via Metropolitan Corporate Counsel: Compliance Function

Project Risk Rating Promotes Transparency

Project uncertainty is represented with risk ratings, so that carbon offset project investments can be evaluated. ...

... "The Carbon Ratings Agency, a subsidiary of IDEAcarbon, will evaluate the various risks associated with an individual offset project and measure the likelihood that it will deliver the emissions reductions expected. " ...

Via Reuters: Project risk rating service

Agile Scope Management

Insurance company uses agile methods to limit scope of software requirements and then increases frequency of releases to build out the appropriate business capabilities, giving IT's customers an opportunity to iteratively describe their key requirements. ...

... "Keith Young, IT director at Standard Life, oversees approximately 500 programmers, and said the agile approach minimises the risk of an application not meeting business requirements. " ...

Via ComputerWeekly: Agile software development

Portfolio Management: Lessons from the Super Bowl, Continued

If you are going to make investments from the high risk, high return segment of your portfolio, you better have the stomach for it. ...

Adoption Risks with Innovation Projects

Whether you are implementing a fundamental new innovation or providing a new way to do things, cultural adoption is a risk you can't overlook. Considering your change management strategy? Do you promote methods that drive addiction or use Frankenstein to your advantage? Read on for some insights. ...

... "Great innovations have foundered over human stubbornness. ... Resistance to technology is an omnipresent risk for every innovator. " ...

Via New York Times: Risk

Project Business Case: Shock and Awe with Value

Enhance your business case with a compelling story and value statements in the language of your business. While the solution is important, keep the technical details to a minimum. ...

... "Decision makers don't want to hear about bits and bytes. IT managers need to talk to them in terms of achieving business value and reducing risk, said John Cash ... " ...

Via IT Business, Canada: Project Approval Process

Resource Planning for Project Success

IT services organization, Parity, sees resource planning as an opportunity to position projects for success. Their whitepaper offers advice that includes a thorough planning period, setting appropriate resource durations to support sourcing arrangements, and a disciplined approach to recruiting project talent. They see shortages in skilled IT resources as a strategic challenge confronting the IT space. ...

... "Failure to get IT resource requirements mapped out adequately is undermining the chances of IT projects succeeding and raises the risk of projects going over time and budget warns Parity ... " ...

Via Parity: Inadequate resource planning puts projects at risk

Project Transparency and Oversight

High-risk government IT projects are on the rise as federal project managers share the facts on their projects. This is a good thing as there's significant investment at risk. ...

... "OMB attributed the increase to better oversight of the projects and better reporting. " ...

Via FederalTimes: Project Management

Project Team Event: Museum Field Trip

Here's an interesting museum you can take your virtual team to. See any familiar items? ...



Pocket Protector Collection

Real World Project Management

There's a good interview on Projects@Work with Susan Snedaker, author of How to Cheat at IT Project Management.

Some key points (paraphrased):

• At status meetings, focus on outcomes instead of endless discussions on issues.
• To insure risks aren't overlooked, appoint a "risk management" person on your project team and/or specify checkpoint milestones on your project.
• To control scope, use past lessons to remind stakeholders of the potential impact of scope creep.
• If you don't like dealing with people ---- well, get out of project management (or at least take a more specialized role on projects).

All good points! Here's the interview...

http://www.projectsatwork.com/content/Articles/236152.cfm

Project Business Case: Watch List

Feds make progress in managing down project gaps as watch list volume decreases. ...

... "The management watch list highlights weak business cases for hundreds of government IT projects. The projects are considered at risk because of deficient acquisition strategies, poor data security measures or flawed design plans. " ...

Via Federal Times: Project Business Case and Watch List

IT Project: Cutover Preparation

Mergers and acquisitions are common in today's markets. These corporate marriages often come with consolidation and integration. Eventually, information systems are consolidated. When systems touch customers, our risk antennae should perk up and we should prepare to minimize business impact. Preparation includes planning, temporary resources, a command center, practice through rehearsing, etc. Read about USAirways post-acquisition preparation for cutover to its common reservation system. ...

... "US Airways has been prepping for the mammoth IT project since the America West-US Airways merger closed in September 2005. " ...

Via Arizona Republic: US Airways IT Integration

Update: Via Bloomberg: USAirways Cutover Issues: "US Airways' kiosks at Charlotte and four regional hubs couldn't communicate with the reservation network for several hours after the systems were unified ... "

Project Management and Driving: Staying Tuned In

It had occured to me the other day that project planning is a lot like driving a car. If you constantly look down at the road in front of you, you won't be prepared if traffic suddenly stops or changes pattern. It's better to look out at the near horizon.

And if you listen to the radio for the traffic reports, you'll be able to avoid problems before you even see them.

It's the same with project management. We need to focus on the current planning horizon as far as we can reasonably see (usually we can only see three-to-six months out with any degree of accuracy). And it's equally important to stay "tuned in" through networking, reading what's happening in your organization and the world, visiting your customers and stakeholders, and practicing MBWA (Management By Wandering Around).

The more we're tuned in to internal and external activities that could impact the success of our projects, the better position we'll be in to address problems proactively and head off a traffic jam or a change in pattern.

Project Management Quotations

Here's a Wiki Quote site with a number of project management quotations. Despite some tired and well worn ones, there are a few gems in there, such as:

"The bitterness of poor quality last long after the sweetness of making a date is forgotten."

"Some projects finish on time in spite of project management best practices."

"The more ridiculous the deadline the more money will be wasted trying to meet it."

"The most valuable and least used phrase in a project manager's vocabulary is "I don't know"."

"The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."

"The project would not have been started if the truth had been told about the cost and timescale."

"You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it."

"All project managers face problems on Monday mornings - good project managers are working on next Monday's problems."

"At the heart of every large project is a small project trying to get out."

"Everyone asks for a strong project manager - when they get him they don't want him."

"Good project managers know when not to manage a project."

"If you don't attack the risks, the risks will attack you."

Enjoy...

http://en.wikiquote.org/wiki/Project_management

Project Management Imperatives: Ten Keys to Success

Someone recently asked me what I felt the critical success factors were for any project (i.e. what were the top "must do's"). Although I can think of many more, here were what I felt were the top ten:

1) Get the roles right. (Insure accountability; use a RACI chart or Responsibility Matrix so roles are clearly defined. Insuring people understand their commitments up front will avoid problems later.)

2) Get the goals right. (Make sure all the key stakeholders agree on the goals. I've seen more projects go wrong for this reason than any other. Time spent here will pay dividends later.)

3) Get the current scope right. (I say "current scope," because change should be expected. Projects by default contain change because they are unique in nature. It's not whether you'll experience change, it's how you analyze the potential impacts and manage the approval of the change that counts. Agreed-upon and approved scope changes are perfectly acceptable, with one caveat: It's often wise to set a limit to the number of times scope can be changed for the current product release, and defer some changes to a subsequent release, else value gets delayed.).

4) Obtain commitment from the business, customers, and other stakeholders as to their part in the success of the project. (Many projects derail because the customer doesn't live up to their side of the bargain, doesn't understand their side of the bargain, or some other necessary constituent isn't cooperating for various reasons. Obtain the right commitment up front, starting with senior management.)

5) Determine the critical success factors and risks. (Critical success factors and risks go hand in hand. Many people ignore this or sweep it under the rug, and accept any related risks as a given. The critical success factors will identify related risks and help set expectations).

6) Set expectations. (This is frequently overlooked and is a key cause of failure. The sponsor, customers, and anyone impacted by the project must be given realistic expectations for what is needed from them, how long the project will take, how much it will cost, what the uncertainty factor is, what the available resources are, and anything else necessary to avoid surprises and/or an under-equipped effort.)

7) Beware of conflicting directives. (I call this the "Robocop Syndrome." In the film, Robocop, the titular robotic policeman goes on full tilt when he encounters directives that conflict with his primary directive. I see this happen often in organizations where a project sponsor demands something that is in conflict with other key stakeholders' wishes and/or top organizational directives. This could be covered under "goals" or "expectations," but it's so important that it warrants its own point. The project manager must head this off at the pass before the project goes down a rat hole it won't recover from.)

8) Plan Collaboratively. (The act of planning is not an isolated exercise. It's a collaborative exercise and should be done with the project core team and subject matter experts via some sort of facilitated brainstorming session---possibly with sticky labels on a wall.)

9) Beware of unilateral and granular "one-size-fits-all" solutions. (This is often ineffective, both as a project management methodology and a process implementation policy. Look at the big picture, and the potential variations. Keeping a framework high-level can allow for greatest flexibility and adaptability. Aim for principles over rules wherever possible. Use rules when safety is involved, regulatory requirements exist, or exact accuracy is needed---per Marcus Buckingham's guidelines from "First Break All the Rules.")

10) Don't let rank set you off course. (Often, a senior manager pulls rank and makes requests that are either detrimental, unwise, or in direct conflict with organizational goals. When this happens, see rules 6 and 7. It is the project manager's responsibility to set the right expectations, warn of potential risks, and head off potential conflicting directives at the pass.)

There it is. My list of "must do's." Project management isn't rocket science. In fact it's not a science at all. It's more of an art. Hopefully, the guidelines above can serve as a useful palette.

Business Results: IT Strategy

Today's IT career path requires evolving your role into a challenging place - the potential to impact business results - which comes with its set of risks. However, standing still increases the risk of outsourcing, or worse yet, irrelevance. ...

... "If they're not in the decision-making stream, playing some role that's accountable for real results from IT strategy, even on a very local, project level, they're at greater risk both to outsourcing and stalling wages. They need to work themselves into a position that's closer to business results and end customers. " ...

Via InformationWeek Weblog: Read

Olympic IT Project: Risk Management Challenge

Atos project team will manage the Olympics IT project for Vancouver games. It manages risks by leveraging accumulated knowledge and experience forward. Lesson learned, knowledge transfer, sustaining core team members, and scaling high-performance teams are all ingredients of successful Olympic technology events. ...

... "In June 2006, only months after completion of the Torino 2006 Winter Games, Atos Origin dispatched IT managers and engineers to already start working on the Vancouver project. Currently the size of the Atos Origin IT team in Vancouver is around 15 but the team will grow rapidly over the next couple of years. During the 2010 Winter Games, Atos Origin will manage the technology consortium team estimated at 2,000 staff, including 400 Atos Origin experts, made up of locally hired staff, local volunteers and overseas Olympic Games technology experts.

The complex, massive IT infrastructure of the Olympic Games is deployed by large teams of people into different cities in different countries every other year. Such a major task is all about risk management capitalizing on the knowledge gained from previous Games Operations. This knowledge and experience transfer is critical in keeping costs down and in lowering the risk of future Olympic Games. " ...

Via Atos Origin: Atos Origin IT Team already in place for the Vancouver 2010 Olympic and Paralympic Winter Games

Project Management Training: Foundation For Success

With federal IT investment slated to increase, info technology professionals in government would be well-served by training in a foundation of project management basics. ...

... "officials interviewed for the study said their teams lacked or may lack sufficient training to effectively estimate costs, identify risks and develop baselines from which to plan project costs, schedules and technical requirements. " ...

Via Federal Times: Link

Brainstorming Power: Apples and Ideas

George Bernard Shaw once said:

"If you have an apple and I have an apple and we exchange these apples, then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas."

This illustrates the power of using brainstorming techiques to generate ideas. For example, using the "Crawford Slip" technique, let's say we had ten people in a room and asked each to take one minute to answer, "What are the top three risks on our project?" Then we ask the same people to take another minute to answer the same question, except they can't reuse the same answers.

Let's say we did this for ten full minutes. We'd generate 300 potential ideas in ten minutes! Sure, there'd be some overlap and sure people might run out of ideas after a few rounds, but still there'd be well over 100 ideas in ten minutes.

Now imagine the magnitude of power when each person in the group learns about all the group's collective ideas for potential risks and then considers them on future projects. The power of brainstorming is exponential.

Project Risk Management

Oil production company, Venture Production PLC, uses risk management software to model project scenarios to select optimum schedule while balancing risks, costs, and time performance. This seems a worthwhile approach, when large investment is at stake and time to value is critical. ...

... "Using Pertmaster, Venture's project management team was able to add a risk dimension to plans built in its Primavera P3 scheduling solution. Venture then analysed the schedule-risk of multiple scenario options to look at the most probable outcomes of each, in terms of both timescales and costs. This enabled the best options to be highlighted when considered from both likelihood of risk occurrence and degree of impact and enabled management to take well-informed decisions. " ...

Pertmaster Helps Bring Venture's New Oil Field On Stream ...

Venture Operated Goosander Field On Stream: "Goosander has been developed as a sub-sea tieback to the Venture operated Kittiwake platform utilising two subsea flowline bundles totalling 12 kilometres in length. The bundles were manufactured and installed by Subsea7 from their construction site in Wick and have been designed and engineered to accommodate future production and water injection wells and the potential for re-use on future subsea tie-backs. "

Major Project Failure: Lessons Learned

There's a good article in Computerworld from Michael Hugos about lessons learned from a major failure.

Three key takeaways from the article (which happen to ring true with what I've been preaching for years) are:

1) Have clearly defined goals and measurable objectives
2) Be sure to have one single leader driving the project
3) Implement in fixed iterations to assure quick wins, earlier benefits, and reduced risks

Here's the full article...

Lessons learned from a major failure

Einstein Project Management Tip #5: Imagination Counts

Our next project management tip from our Einstein series regards the need to challenge the status quo----to think out of the box. Consider this quote:

"To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advances in science."

Of course, Einstein also famously said, "Imagination is more important than knowledge." To a project manager, who's typically focused on things like scheduling, monitoring, reporting, and driving the team to completion, this can be a particular challenge. But it's important nonetheless.

Imagination is required in many situations, including (but not limited to):

• Achieving success when the odds are against you
• Conceptualizing ways to achieve the objectives more effectively
• Brainstorming solution ideas and possible risks
• Overcoming barriers, whether political, technical, or physical
• Improving the cusotmer experience

For some practical advice on building the right team for innovation, see my blog series on Tom Kelley's The Ten Faces of Innovation.

More to come.

Einstein Project Management Tip #2: Think Flexible

In keeping with our Einstein theme, here's our next project management tip from the great thinker himself.

"As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality."

While Albert Einstein was referring to the laws of mathematics, surely this applies equally to project plans. We lay out in fine detail what we think is the ultimate plan that supposedly reflects reality. We make what we think are valid assumptions. Then, the minute it is published, things change. Life has a habit of doing that, despite our best intentions.

But we still need to go through the act of planning if we are to think through the risks and have a good chance at success.

Therein lies the paradox. We need to plan, and then we need to constantly revise the plan to match reality. Then we need to plan again. It's a continuous iterative process of course-correction. Perhaps it's why Eisenhower said, "Plans are nothing. Planning is everything."

For most projects, the old adage,"Plan the work and work the plan" should be taken in a different context than its original intention. We need to plan the work, and then we need to "work the plan" (meaning "continuously adjust the plan so that it remains adaptable") , as opposed to merely working "to" the plan.

Stay tuned for more Einstein project management tips.

Strange Project Risks: Mystery Woodpecker Halts $320 Million Project

Here's one that probably won't turn up on anyone's project risk template. The $320 Million Grand Prairie Irrigation Project, being led by the Army Corps of Engineers in Arkansas, has just been put to a halt by a federal judge because a rare, thought-to-be-extinct (and maybe still extinct) woodpecker was allegedly sighted two years ago.

The ivory-billed woodpecker was apparently spotted by a kayaker in 2004, which triggered a series of petitions and lawsuits by environmentalists to stop the project. The bird hasn't been seen since. Of course, I'm sure there are environmental issues beyond just the woodpecker, but the woodpecker seems to be the driver behind the decision.

According to the Houston Chronicle, about $80 Million has been spent so far, with a goal of delivering water to farmers by 2010 or 2011.

Here's the story...

Woodpecker Halts Ark. Irrigation Project - NEWS - US NATIONAL - Comcast.net

Project Management Lessons from Mars

Brian Muirhead, the project manager for the Mars Pathfinder program, had some good tips to share with Projects@Work this week.

Some key learnings, extrapolated from the interview:

• Innovation and bold ideas are often necessary to meet what often seems like an impossible challenge. The trick is to balance the cost and time savings with the risks.
• A diverse team is key. It's better to have people that are different, with complementary skills, than have a bunch of people who think and act the same way.
• A small core team that can share issues, problems, and resolutions, with one person at the helm, is an effective way to run a project.
• Trust, honesty, and personal committment are traits that need to be prevalent throughout the team.
• Test, test, and then test again. Don't rely on luck. If you can't test using the exact situation, then simulate it as best you can, testing as much as is possible.
• A team is only as good as it's weakest link. It's up to the project leader to identify those people that aren't up to the task and remove them or find an area that suits them better.
• Ensure team members have opportunities to make personal connections and grow.
• A project manager must simultaneously provide the glue (keeping the team cohesive and focused) and the grease (removing barriers).
  
  Here's the full interview...
  
  http://www.projectsatwork.com/content/Articles/232113.cfm

One-Page Project Status Report; Keeping it Brief

There's a great writeup in Projects@Work about project status reports, including tips on meeting format and frequency as well as a format for a one-page status report.

According to the article, there are 5 Project Status Best Practices:

1. Consistency — The status process should be basically the same for large and small projects, and consistent with their measures of success
2. Escalation — The status process provides a mechanism for escalation of key issues.
3. Simple — One page with the ability to drill down for details when necessary
4. Public — Status is available to all (as appropriate) in order to communicate issues, risks and corrective action measures
5. Inclusive — All projects are required to provide status on a consistent set of metrics

For busy managers who see loads of project status reports, it's much easier to have a consistent, brief summary of what's really happening on each project. They don't need a dissertation on all the details, nor will they get a clear picture just looking at performance metrics. Much like on a business case, most just want the executive summary. Simpler is better. Less is more.

For those looking to improve their status reports (and their credibility with management), read on...

http://www.projectsatwork.com/content/Articles/231704.cfm

Project Risks; Let's Talk About the Weather

When doing risk planning for your project, don't forget about seemingly off-topic risks, such as the weather, or the season of the year. It's an obvious concern if you're in the construction or farming industry, but in many other organizations, timing your project rollout to avoid quarterly closes, the company's peak season, or any other major seasonal events, can make or break your project.

I've heard of one popular confection organization that couldn't ship candy during Halloween because of a problem with their new SAP implementation. Bad timing. Another company that dealt with agriculture had to have a project completed before the summer growing season. They were smart enough to list that as a constraint.

The seasonal elements didn't just affect Napoleon in his failed Russian campaign (and many before and after him). It can affect those of us in business as well.

Project Management Lesson from Carpenters

No, not the brother and sister duet, I'm talking about real carpenters. There's an age-old axiom used by carpenters: "Measure twice, cut once." Experienced carpenters know that there's no turning back if you made a mistake measuring once the wood is cut.

This is good advice for project managers as well. Many errors, and many hours of rework, can be avoided if you take the time up front to do the proper research, planning, and risk analysis. It's well worth checking your plan twice, even though circumstances are likely to cause you to deviate from the plan. But even those risks can be mitigated with proper research and meditation up front.

Just like carpentry, the later mistakes are caught, the more costly and devastating they are likely to be. It's better to spend a little extra time up front on your projects to increase the overall speed and success of the project.

Join the Project Management Revolution; The SOPM Model Takes Shape

OK, I've been fleshing out the Service-Oriented Project Management (SOPM)™ model, and have come up with a more memorable and catchy representation of the four steps, although the actual content is pretty much the same.

The acronym for the four phases is UP-IT (which can symbolize "upping" the level of customer service, saying "up yours" to old ways of doing things, or "upping" the success rates of IT projects---in which case the "it" stands for "IT").

Ready??? Drum roll please......

The four phases are:

• Understand
• Prepare
• Iterate
• Transform

Here's a revision of my previous post on the topic...

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer and what they need to be successful.

2) PREPARE ... After helping the customer obtain approvals if needed, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Using the axiom, "Think bold, implement safely," plan, design, build, test and pilot the solution before attempting a full scale implementation. Encourage innovation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) TRANSFORM... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected) for the purpose of transforming yourself and the customer for the better. This includes guiding the customer to help them achieve maximum results with the product or service delivered, and laying the groundwork for their continued success.

Now that I have the framework locked in, I'll complete the model around these four phases. I am absolutely convinced that this model can help increase customer satisfaction and the general success rates of projects.

SOPM; A New Project Management Methodology

Service Oriented Project Management (SOPM) is taking shape as a methodology that fills the gaps in traditional project management, namely a RELENTLESS customer focus and the all-important analysis and benefits evaluation after the project has "completed."

As I fine tune the model, I'll post the iterations here, as a methodology in progress.

The four high-level steps in SOPM are as follows:

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer.

2) ENABLE ... After helping the customer obtain approvals, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Plan, design, build, test and pilot the solution before attempting a full scale implementation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) EVALUATE... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected). This includes evaluating how the customer can achieve maximum results with the product of the project, and laying the groundwork for their continued success.

By using an UNDERSTAND, ENABLE, ITERATE, and EVALUATE process, with COMMUNICATE as an overarching activity that extends across all four steps, we adopt a much more holistic and customer-centered approach to project management.

A few key points... Customer satisfaction should be measured at milestones throughout the project, not just at the end. It's as important as monitoring cost and schedule (i.e. Earned Value performance).

Imagine seeing an S-Curve showing Planned Value, Earned Value, Actual Cost, and Customer Satisfaction. Maybe your project is on schedule and on budget, but the customer isn't satisfied with the results (or with the project communication, or a whole host of other issues).

A narrow focus on cost and schedule takes too much of an inward view. Besides, measuring customer satisfaction throughout a project allows for corrective action instead of managing in the rear view mirror.

More to come.

NOTE: I have since revised this model. See my updated entry.

IT Governance Conference: Enron Watchdog Keynotes ...

Sherron Watkins, Enron, keynotes at upcoming IT governance conference ...

... "According to the IT Governance Institute (ITGI), IT governance is now considered as critical a board and management discipline as corporate or enterprise governance. Effective IT governance helps to ensure that IT supports business goals, maximizes business investment in IT, and appropriately manages IT-related opportunities and risks. Such risks include legal and financial consequences stemming from non-compliance with corporate accounting legislation; namely, the Sarbanes-Oxley Act.

One key figure recognized by TIME magazine for her courageous actions during a high-profile corporate scandal that triggered the landmark Sarbanes-Oxley Act is Sherron Watkins, former Enron VP. Pink Elephant is pleased to welcome Ms. Watkins as one of the symposium’s keynote speakers. " ...

Via Pink Elephant: Sarbanes-Oxley Challenges Meet IT Best Practice ...

High Risk and Reward Projects Enabled through Partnerships ...

Oil and gas company, Encana, manages risks in unlocking the value of hydrocarbons from oilsands bitumen. The company will partner to realize the value of its assets from high risk / reward projects. ...

... "Regrouping from that defeat, EnCana is busy on Project Apple, with associated files codenamed Granny Smith, McIntosh and the like. The company has said it assessed more than 20 proposals from potential partners. " ...

High Risk and Reward Projects Enabled through Partnerships: Via globeandmail: EnCana puts the polish on Project Apple ...

Project Failure Case Study; Maine's Medicaid System

Talk about a project disaster. As reported in an excellent article in CIO Magazine, the Maine Medicaid Claims System project is a case study of a project gone awry.

The project was undertaken to switch from their legacy systems to a new web-based system to process Medicaid claims and facilitate HIPAA compliance (Health Insurance Portability and Accountability Act of 1996). As a result of the failed project, Maine is now the only state in the union not in compliance with HIPAA.

System problems led to many claims ending up in limbo, leading to hundreds of calls from health care practitioners, nearly 300,000 patients being turned away, several dentists and therapists going out of business, and destroying Maine’s finances and credit rating.

So what went wrong?

Mistakes included the following:

• Deciding to develop an entire system from scratch using unproven technology, while other states built a front-end onto their legacy systems
• Caving to pressure from management to meet tight deadlines with inadequate resources instead of pushing for a realistic plan to begin with
• Failing to notice why other bidders either didn’t bid or came in way higher (a sign that the schedule was unrealistic)
• Hiring a vendor with no experience in developing Medicaid claims systems because they were the lowest bidder
• Not having a Medicaid expert on the team, leading to errors in judgment
• Underestimating the time needed to meet with subject matter experts
• Competing with another major initiative (a department merger) for executives’ attention and resources
• Skipping project management basics (including piloting, adequate end-to-end testing, staff and user training, etc.) due to looming deadline pressures
• Failing to stop, regroup, and analyze the risks
• Taking a “big bang” approach to cutover with no contingency or backup should something go wrong

Management’s response, of course, was to switch program managers, and issue stronger demands to have a smooth system, but none of the changes or demands made much of a difference. Consultants were brought in to prioritize the many problems, but still, the complexities proved too much. It wasn’t until a Medicaid expert was brought in that things began to gel.

Like many project failures, it’s easy to point to the project management (and certainly there are many shortcomings there in this case), but the organization must share the blame as well if it insists on unrealistic deadlines and leads by fear (fear of shareholders, fear of competition, fear of management, etc.). None of these variables can make an unrealistic schedule more realistic.

It's really very simple. Either adequate resources must be committed, the expectations lowered, or a more piecemeal approach taken (or all three, if applicable). In any case, the schedule must be realistic and risks need to be managed.

Here's the full article. It's well worth reading, as are the reader comments.

Maine's Medicaid Mistakes - Editorial - CIO

Vendor Management: OnDemand Increase Risks ...

OnDemand business models may increase risks requiring more vigilant vendor and contract management. Watch those terms and conditions ...

... "The same goes for hardware, where computing power is sold on demand. These business models can bring customers more flexibility, but also more risk and uncertainty. Hence the need for better vendor management. " ...

Vendor Management: OnDemand Increase Risks: Via globeandmail: Without counsel, vendors have you by the fine print

Personal Value Proposition: Assess Your Business Impact ...

Nice article, by Pete McGarahan, challenges the reader to assess how they contribute value to an organization and be accountable for their future by taking risks, learning, and owning their personal development. Quick and worthwhile read ...

... " ... a business mentor once asking me, What's your value proposition to the organization? I was taken aback by the question and began rattling off what I did for a living. He quickly stopped me and said, No, Pete, what value do you provide to the organization on a daily basis? " ...

Personal Value Proposition: Assess Your Business Impact: Via CCN: Being the CEO of You (PDF) ...

Project Risk Control vs Innovation

Winston Churchill once said, "The optimist sees opportunity in every danger; the pessimist sees danger in every opportunity."

As project managers, we are taught to focus on reducing or avoiding risk, but all too often we forget that a good risk management plan should include opportunities as well. Sometimes those opportunities will carry additional risks, but if the benefits are worth it, we need to exploit those opportunities. Certainly we can---and should---try to mitigate the risks, but the point is that in focusing on the dangers, let's not overlook the opportunities.

When framing a project, it's important to see for ourselves what the customer's situation is, and get engaged an an "opportunity assessment." As Tom Kelley of IDEO pointed out in The Ten Faces of Innovation, Henry Ford said that if he'd merely asked customers what they wanted, they would have said a faster horse.

Of course, not every opportunity will make it into the scope of the initial project, but at least there can be a plan to exploit it.

So, using Winston Churchill's axiom, should project managers be optimists or pessimists? I'd venture to say we need to be a little of both, and the right balance is the art of project management. For more on how innovation and project management can and should coexist, stay tuned for my upcoming post on the relevance of Tom Kelley's book to project managers.

How to break the glass ceiling

I just can't ask a question (see my blog below) without offering a solution.

If you don't look out for #1, you won't become #1.

Tips for breaking through the glass ceiling:
1) Hobnob with the bigwigs
2) Don't nitpick
3) Sell yourself
4) Ask for more money
5) Have fun
6) Take risks

Click here Are Women Happy Under The Glass Ceiling? - Forbes.com, go to the bottom of the page and click on "Click here to learn how to break the glass ceiling" for more detail about these tips. It's worth 3 minutes of your time!


See my post below

Why Projects are Late; The Top Six Reasons

Here are the top six reasons why projects are late and what we can do about it...

1) Unrealistic Deadlines - As we've reported here before, this is one of the most frequently overlooked reasons for late projects---and unfortunately, often the last thing people look at.

Solution: It's imperative for a project manager to defend the right plan and not give in to pressure to sacrifice good principles. If necessary, negotiate to time-box the project into multiple phases.

2) Customer/Partner Availability - I've seen numerous project managers over the years talk about the challenges they face keeping a project on schedule when they're waiting on a customer or business partner to do testing or sign off on some deliverable.

Solution: Set milestones, monitor progress, and raise an issue if the lack of availability will cause a delay. If necessary, negotiate a new project baseline---which may be quite appropriate if the customer and/or steering team agrees that a delay is acceptable.

3) Resource Availability - There's nothing worse than putting together a reasonable schedule only to have your key resources pulled off into different directions, but it happens more often than we care to admit.

Solution: Try to obtain full commitment up front for your resources' time. Even so, unexpected conflicts will happen. Same as #2 above, set milestones, monitor progress, and raise an issue if needed. Again, negotiation may be necessary, which can result in getting your resources back or in setting a new project baseline to accommodate the new priorities.

4) Uncertainty - Especially in the IT field, uncertainty is a given. At any time, unexpected circumstances may cause project delays.

Solution: Use rolling wave scheduling, planning the whole project from a high level, but only the nearest 90-day horizon in detail. Try agile approaches as well, aiming for prototypes and frequent iterations. Ideally, pilot the project, and aim for vertical rollouts (one group at a time). Build contingency into your schedule for known risks. Most of all, manage stakeholder expectations.

5) Management Decision - Sometimes, management makes a conscious decision to delay a project, either for strategic needs, changes in priorities, or any number of reasons.

Solution: If the delay is a management or customer decision, a new project baseline should be saved, with current metrics based on that. Note that it's also important to keep the original baseline, as that offers a different set of measures (mostly around organizational alignment).

6) Poor Estimates - Sometimes a project is late simply because tasks were underestimated or omitted from the schedule. Although this is not always the cause of project delays (and rarely the only cause), it tends to be the first one people look at.

Solution: Build experience and capture historical data by project category and activity. If the data isn't categorized it won't be useful. Create and maintain checklists of items to consider. Build project schedule templates. The most frequently overlooked areas in IT are: training, data-loading, cutover preparation, system network testing, adequate QA testing, and documentation.

Risk analysis for portfolio management

"CIOs who are serious about portfolio management need to be serious about statistical risk management". This sentence is tucked away soemwhere in the second section of this article, but it summarises the message.
An interesting insight is that many organisations can't or won't quantify project risks. Because there are no risk numbers to be compared with the one hard number that is know - the budget - the tendency is to base portfolio decisions on budget alone.
The articlae discusses a couple of methods for quantifying risk - Decision tree analysis and Monte Carlo.
And the bottom line? It's a question of leadership to ensure that risk is taken into account.
Playing with Fire - Risk Management - importance of quantifying risk; use statistical simulations to map risks and probabilities; Develop risk analysis process - CIO Magazine Jul 1,2003

Risk Analysis

Oil exploration is a notoriously risky business. Add in the physical risk of deep water drilling and you can easily understand why risk analysis and management takes on a really high profile in the off shore drilling industry.
DNV is a long established maritime certification organisation and, with the North Sea oil boom, has moved naturally into the off shore oil exploration risk management and certification business.
This paper describes an approach to risk management for deep water exploration. It is written with a general approach and is adaptable to other styles of project and product.
A couple of perspectives that make it particularly interesting:
The risk analysis - and management plan - will be different for the organisation executing the project and for the contractors;
The categorisation of risks by Economy, Time and Performance - equivalent to Cost, Schedule and Scope. The familiar Probability/Impact matrices are represented for each of these and the authors use an interesting method of plotting the effect of risk mitigation plans on the analysis.
There is also extensive discussion of the risk management process, use of the risk register and communication. It ends with a couple of case studies that illustrate the approach nicely.
DNV Risk Analysis

Agile vs Big-Bang Project Delivery; Argument Solved

For years now, proponents of realistic IT approaches have been touting the importance of agile or spiral development. And aficionados of traditional "plan everything up front" approaches have been counteracting this by stating the need to agree to a fixed scope, and stay on time and on budget.

Several weeks ago I mentioned an excellent book that addresses this subject; Software Projects: Evolutionary vs. Big-Bang Delivery, by Felix Redmill. I finally finished reading it, and it points out how to resolve the differences, with a reasonable and sensible approach.

Again, the book is expensive (well over a hundred dollars), but can be found used for around fifty dollars on Amazon.com.

Below, I've paraphrased and summarized the key points:

• Be sure to understand and state the business objectives up front. This is too high level for an adequate estimate, but it's a start.
• Then conduct a feasibility study, analyzing as much detail as possible before authorizing the project. Most organizations skip this step, with bad effect. Aim for an aggressive but realistic target.
• Beware of random constraints assigned by senior management, with no strategic cause. Most projects fail because they attempt to hold to unrealistic or arbitrary constraints. If necessary, document the risks of adhering to the arbitrary deadline and review with them. Negotiation tradoffs in scope, time, or cost as needed - or break the project into multiple phases.
• It's still too soon for a definitive estimate, but the results of the feasibility study should be submitted as an "order of magnitude" estimate, along with risks and a plan for mitigating them. This becomes the business case for the project.
• Make sure senior management understands that change is inevitable as the project progresses. But this change should be still be governed and weighed against the business objectives. Reassessment gates can be used to reset expectations of when the project ends.
• Not all change should require governance. Project managers should have the leeway to use their own judgment to change tactics accordingly as long as it's within the business objectives. They should not just "follow procedures."
• It should not be expected that all work will be done within the confines of the original document. For instance (and this is my example, not from the book), if implementing a purchased software project, a feasibility study would have been done before the software was purchased, configured, and tested. Upon configuration or testing, new discoveries/issues can (and probably will) occur. The only way to truly mitigate this is to do a pilot. Aside from that, expect changes.
• This is a HUGE culture change for most organizations on the part of senior management. Without this level-setting, management will expect all work to be held to the original estimate, and judge success against it. This is the key reason why most IT projecst are seen as failures. We must manage stakeholder expectations (and that includes senior management).
• Project progress should be weighed regularly against business objectives and not the completion of tasks. These objectives and the project's ability to meet them should be reassessed at each phase gate, with escalation of any variances to management. Again, this is the time to reset when the project ends, if necessary. This is also a huge culture change for senior management in most cases.
• Scope should be revised as needed and documented at each step, so there's a record of the approvals and rationale for changes. Reasons of variations should be captured as lessons for future estimating.
• Agile or evolutionary development is not an excuse to ignore change management. But change must be expected. To hold firm to a detailed schedule up front is not realistic for most IT projects.
• Maintain close contact with users throughout the project to assure success.

This sounds like a sensible approach, but does require level-setting with management. Again, many project failures are a result of not setting the right expectations with management. Otherwise, a project can be a complete success, but management is dissapointed. This destroys morale and unfairly judges the project as a failure.

I recommend the book for those who want to learn more, as the book goes into far more details and offers examples, processes, etc. Here's the Amazon link...

http://www.amazon.com/gp/product/0471933430/102-4494239-8790520?v=glance&n=283155

Troubled Project Dilemma: Fix or Kill?

We've all been faced with projects that run into unexpected problems. It happens to the best of us. Sometimes, despite the best of planning, things can begin to go south. The situation may be that the project now risks running overbudget or being delivered late, or it may be that unanticipated quality problems were discovered.

Our first action should be to not overreact and to try to fix what's wrong, working out alternatives if needed. But if all else fails, then we may be faced with a tough decision. Do we continue to fix it, accept the situation and manage expectations, negotiate a change in schedule, budget, or scope---or do we kill the project?

Similar to going bankrupt, killing a project late in the game should only be a last resort. Even then, there's a right way and a wrong way to go about doing it. The article below from High Context Consulting offers some good tips, most of all that an alternate solution must be proposed.

Specifically, it says:

• Build a case including alternate options to meet original needs.
• Gain support of stakeholders and a champion.
• Present recommendations to leadership.
• Do not play the blame game.
• Learn!
  
  Here's the full article...
  
  High Context Consulting � Blog Archive � On Killing Projects

VOIP Project: Voice-Over-IP ...

The VOIP transformation project is relatively high-risk: newer technology, questionable scalability, increased cultural change, and impact to a critical business function: communications. J. Nicholas Hoover discusses the pitfalls of a voice-over-IP phone project

... "Anyone thinking a switch to a voice-over-IP phone system will be smooth and easy should remember Ruth Harenchar's ruby-red nail polish. At the Hobart West Group, where Harenchar is CIO, the company's VoIP project required tough decisions, like whether to spend money training existing IT staff or hire expensive consultants. It meant learning to live without certain common telecom features in order to get the savings the company wanted. And it involved helping employees through the culture shock of replacing the familiar ... " ...

Via InformationWeek | Voice-Over-IP | VoIP Gotchas ...



Here are some relevant references on VOIP implementations:

Via NetworkWorld: The ROI of VoIP: "When it comes to VoIP, most network managers are satisfied that the technology works. The challenge is developing cost analyses: What will the new technology cost to roll out and support, and what benefits can companies expect to reap? "

Via NetIQ: VoIP in Action: "OK, you've moved beyond the deployment stage of your VoIP project. Your first group of VoIP phone users are happy and you've got high levels of availability and call quality. Now what? In the management stage, you need to keep those users happy with consistent availability and high call quality. "

Managing VoIP Implementations Effectively: "Voice over IP (VoIP) is the hottest telephony technology. Consumers and corporations are looking to reduce costs by deploying VoIP systems. The challenge, however, is that the technology is so new that few project managers have expertise in managing VoIP implementation. If you are interested in or responsible for implementing VoIP at your organization, this is the course for you. "

Project Management Audit

It's not often that you get the opportunity to look inside someone else's project in an objective way while it's still in progress. This audit report from the Treasury Board of Canada is interesting in the depth to which it goes in identifying risks - and in showing the importance the secretariat gave to addressing the concerns.
One issue that will be familiar to many people working with a client (internal or external) to deliver a system is the availability client staff. One can almost sense the Project Manager's frustration at not being able to access knowledgable staff even though the importance had been made clear at the outset and the budget for back-filling approved.
Another familiar issue is the argument amongst stakeholders over the project scope. This is the one item that the audit team rated as High Risk. And credit to the secretariat for setting up a new steering committee chaired by an Assistant Secretary to address the issue.
All in all, an intersting read.
Project Management Audit - Treasury Board of Canada Secretariat - Part 2 of 2

IT Governance: COBIT 4.0 Release ...

The new edition of COBIT 4.0 is ready for release and focuses on the role of IT governance. ...

... "The IT Governance Institute (ITGI) will release on 16 December a significant update of Control Objectives for Information and related Technology (COBIT), an internationally accepted IT governance framework used by major companies worldwide. COBIT provides an authoritative, international set of generally accepted practices that help boards of directors, executives and managers increase the value of IT and reduce related risks. " ...

IT Governance: COBIT 4.0 Release: Via ISACA: COBIT 4.0: Major Update to International Standard Helps Businesses Increase IT Value, Decrease Risk

Tag: IT Governance

SOX SarbanesOxley: IT Asset Management: Webinar

Peregrine and Protiviti collaborate in Web Seminar, Dec 8, on driving SOX Sarbanes-Oxley compliance through better management of information technology assets. ...

Via Peregrine: Peregrine Systems and Protiviti to Participate in InformationWeek TechWebCast on Sarbanes-Oxley and the Role of IT Asset Management ...

... "The WebCast will take place on Thursday, December 8 at 9:00 a.m. PST, and will discuss how organizations can minimize the total cost of ownership for IT assets and mitigate the risks associated with software audits. Although a number of major milestones have been met since Sarbanes-Oxley regulations were enacted in 2002, there is still a long way to go to achieve effective long-term compliance, especially within the IT organization. During this discussion, experts from Peregrine and Protiviti will draw on their experience working with business and technology leaders to offer advice on what's necessary to meet Sarbanes-Oxley compliance requirements and discuss a fast track approach to establishing leading IT Asset Management practices. " ...

Project Implementation; Software Rollout Approaches

When analyzing alternate approaches for rolling out a new software product, consider information density versus percent of population.

For example, you can start with low information density (less functionality, fewer features, etc.) in a large percent of the population (or for everyone), and then roll out more features over time.

Or you can start with high information density (heavy or full functionality) for a small percent of the population (i.e. a pilot group), and then roll it out to wider audiences over time.

Neither approach is wrong. It all depends on the situation, the nature of the product, and where the risks lie.

For example, if the audience for the software can be isolated easily and there are no major issues with rolling out to wider audiences piecemeal, then it may pay to start with high information density in a pilot group.

But if there are major risks to rolling it out piecemeal (such as a need to maintain multiple systems, etc.) and basic features will do for phase 1, then the alternate approach might be a better choice.

One thing's for sure. To begin with high information density in a large or total percent of the population is usually a mistake (unless the full information density is necessary for the product to work, in which case the schedule needs to include time for full rollout and extra testing).

Just some things to think about when planning your next software rollout.

IT Governance: COSO Cobit Integration with ESAS ...

IT governance needs to manage the risks associated with SOX compliance. Doug Henschen explores the ESAS methodology employed by Chevron information technology organization to manage its complexity and risks. ...

IT Governance: COSO Cobit Integration with ESAS: Via Intelligent Enterprise: Chevron IT Risk Initiative Spurs Corporate Compliance

... "ESAS is compatible with some of the open frameworks now emerging for IT governance. For example, Chevron is an ITIL shop, and Brabeion says it's incorporating the COSO and CobiT frameworks into ESAS ... " ...

Earned Value Management System: Risk Perspective ...

ASC will identify, manage and mitigate risks on its military projects using Welcom's software, which complements its existing use of the earned value management capabilities. ...

Earned Value Management System: Risk Perspective: Via Welcom: Australian Submarine Builder ASC Pty Ltd Chooses WelcomRisk ...

... "ASC has been using our Cobra project cost and earned value management system since 2002, and we see the selection of WelcomRisk as a further endorsement of WST Pacific and Welcom's project portfolio management solutions, said Steve Cook, president of Welcom. " ...

WelcomRisk is a formalized risk management tool for the proactive identification and mitigation of business risk, both threats and opportunities. WelcomRisk combines a user-friendly interface with a higher level of flexibility and granularity than other products. Its flexible integration capabilities and tight security provide companies with a better solution across the enterprise. WelcomRisk is part of WelcomSuite™, a comprehensive solution that supports portfolio analysis, project collaboration, planning and scheduling, and cost and earned value reporting.

IT Governance: Avoid Unintended Consequences ...

Avoid these unintended consequences of IT governance: Inefficiency and increased risks ...

IT Governance: Avoid Unintended Consequences: Via InformIT: IT Governance: Toward a Unified Framework Linked to and Driven by Corporate Governance ...

... "The operational reality in many of today's organizations is that IT governance is conducted as an unaligned set of activities based on a mix of competing micro-theories, the unintended consequence of which is the creation of the very inefficiencies and risk exposures that governance mechanisms are intended to address. " ...

ITIL Methodology: Sun Preventive Services Offering ...

First Data leverages Sun Microsystems Preventive Services offering to manage risks. ...

ITIL Methodology: Sun Preventive Services Offering: Via Sun Microsystems: Hundreds of Global Customers Choose Sun Microsystems in Fiscal First Quarter ...

... "After working closely with Sun to explore technologies and programs such as Sun Preventive Services, an assessment and mitigation offering that utilizes ITIL methodology, First Data Corporation agreed to adopt SPS as a strategy for risk aversion. Sun is evolving the relationship with First Data, demonstrating through the provision of committed resources and teaming that additional focus on prevention and operational excellence can yield a positive ROI. " ...

Project Management: Spiral Development Definition

Project Management: Spiral Development Definition: Via Federal Financial Institutions Examination Council: Development and Acquisition Glossary: Spiral Development Definition ...

... "Spiral Development: An iterative project management model that focuses on the identification of project and product risks and the selection of project management techniques that best control the identified risks. " ...

Additional spiral project management references:

Spiral Development: The spiral model encompasses features of the phased life cycle as well as the prototype life cycle. However, unlike those life cycles, the spiral model uses risk analysis as one of its elements. ...

System Life Cycle (SLC) is defined as a structured development approach with defined activities, phases, products, and reviews that provide a standard to support the development of systems from identification through implementation, operation, maintenance, and eventual retirement. The systems life cycle process is a basic requirement for systems development. There are a variety of life cycle models, such as: waterfall, spiral, evolutionary, decomposition (or stepwise refinement), and formal transformation. The choice among the models is made based on the specific project. ...

SDLC Process: Discusses the application of software assurance best practices in the context of various SDLC methodologies, including RUP, XP, Agile, Waterfall, and the Spiral Model. ...

Project Control and Leadership; The Two Faces of Project Management

There are those who think of project management as primary a control function (i.e. controlling cost, schedule, scope, etc.). Then there are those who view project management as primarily a leadership function--leading and facilitating a large team to complete mission-impossible milestones and removing barriers as fast as they appear.

Well, in reality, it's a little of both. But to really be effective in the latter, it's often helpful to have some assistance in the former. I've mentioned this before but it's worth mentioning again. If it's at all possible to have a separate person handle much of the project control and administration funtions (owning the issues list and risk list, maintaining the schedule, handling project accounting, etc.), it'll make it that much easier for the project manager to be successful with the all-important job of leading the project. This is especially important for large projects.

All to often, project managers get so caught up in the "mechanics" of project management that they forget to actually manage the project. This doesn't mean the project manager is oblivious to the issues list, risks, and schedule, merely that a separate person maintains these items. On the contrary, analyzing the schedule, issues and risks are a key part of leadership.

Business Strategy: Align Objectives and Execute

IBM launches new software that enables workers and managers throughout an organization to align their personal and departmental objectives with business strategy and drive execution of their workplace activities ...

Business Strategy: Align Objectives and Execute: Via IBM: IBM Software Helps Employees at All Levels Align Their Objectives With Company Strategy ...

... "According to feedback from IBM's customers and partners, more companies are recognizing that while they have lots of data and a sound business strategy, the execution of the strategy needs improvement. IBM Workplace for Business Strategy Execution helps employees understand their company's strategy in concrete terms, focus on what is important, and remain current on status and risks. A department leader can use IBM Workplace for Business Strategy Execution to clearly communicate team objectives and how they fit into the company's strategy; link to and monitor internal and external dependencies that could affect the ability to reach objectives; track progress toward the objectives though intuitive scorecards and dashboards; and initiate actions to correct gaps in performance. " ...

PMThink references on strategy and alignment:

• Achieve Strategy Execution: Accelerate Plan Funding Support


• Business Continuity Project: Key Part of IT Strategy ...


• Business IT Alignment: Business-Relevant Metrics


• Business IT Strategy: Successful Alignment


• Governance Alignment: Project Portfolio Management (PPM)


• IT Alignment: Cost Benefit Analysis ...


• IT Governance: SAP ESA Strategy


• IT Strategy: Motorola Exec Podcast ...


• ITIL: IT Service Catalog: Alignment Focal Point ...


• Microsoft Framework: Business IT Alignment


• PMO Role: Align Business and IT ...


• Project Failure: A Success Strategy


• Project Management Strategy Integration Conference December2005


• PublicSector CIO: Enterprise View IT Strategy


• Software Aligns Project Management With Enterprise Strategy: Enhanced Portfolio Analytics ...


• Strategic Alignment: Project Portfolio


• Strategy: Visualize the Design ...

More Project Management Equations; The Triple Constraint Override

With nearly 30 years in IT, I've come across pretty much every situation, whether it was managing commercial software product development, acquisitions and divestitures, systems conversions, you name it. And over that time, certain things jump out as tried-and-true principles.

One of them I call the triple constraint override. That is, irregardless of the usual triple constraint of time, cost, and scope (I won't get into the other four possible constraints), I have my own principle that overrides all that.

It involves two simple equations:

Speed is more important than cost.
Success is more important than speed.

In other words, if we act fast, cost will usually follow naturally. Delays can increase cost exponentially, whether it's the cost of lost opportunity, the cost of reduced momentum, or any other number of costs associated with the risks of delay. Sometimes, it might appear that we're spending more money by rushing (such as paying a little more for a service rather than waiting to get the best deal), but in the end, what is really saved by waiting? I argue that there are hidden costs in waiting that can negate any gains.

But even speed must take a back seat to success. Notice I didn't say quality. That's because it's not about perfection. It's about the success of the project, whatever you take that to mean. If speeding things up risks the success of the project to the point where there's a 50% chance or less of success, then the speed has turned into haste and it's a sign to slow down and develop a more realistic plan.

Like any rule or principle, there are exceptions, especially during some negotiation situations. but we must consciously make that decision after weighing the situation against the two simple equations I've mentioned.

Just something I thought I'd pass along.

Project Schedule Critical Path ...

Project Schedule Critical Path: Via Yackity Blog Blog: Critical Path in Schedule Management

Post on project management critical path concepts ...

... "Project Management Network Diagrams are helpful in determining where most of the schedule project risks will occur. A critical path is made up of activities that cannot be delayed without delaying the end date of the project. " ...

ITSecurity Professional: Project Career Path

ITSecurity Professional: Project Career Path: Via Musings on Information Security :: Who gets to manage security?

Discussion on career path progression for IT security professionals and how business experience gained from project management may be a catalyst for future success ...

... "In a company to manage risks it requires business sense which many security techies may not have - business sense involves communication skills, project management skills and political skills. " ...

IT Risk Management: Disaster Recovery Planning: Forward Placement

IT Risk Management: Disaster Recovery Planning: Forward Placement: Via Data Foundry: Garden Ridge Selects Data Foundry For Disaster Recovery Services ...

Excellent point on risk management in IT when planning for disaster recovery, consider forward placement to avoid collateral impacts on the secondary site ...

... "Bob Janusaitis (CBCP, CISA, CISM), a 25-year veteran in IT disaster recovery planning and CEO of Business911 International, Inc. specializing in IT Governance and Risk Management, stated, It's been my experience that too many companies overlook all the risks associated with implementing a disaster recovery plan that calls for the secondary site to be located in the same city as their primary site. The risks of implementing this strategy range from shared city power grids, inability to traverse local streets, over subscription to the local facility, and the affect on human capital that supports the secondary site in a true disaster scenario. I encourage a forward placement philosophy which calls for getting people and data out of harms way if at all possible. This means putting distance between the disaster event and your secondary site. " ...

Data Foundry is a pioneer in the business ISP industry and Data Center Services market. Founded in 1994 – profitable then and still profitable today – Data Foundry supports over 1,000 corporate customers with unparalleled Managed Internet, Enterprise Data Center, Colocation and Disaster Recovery services. As a Texas-based Global Managed Services provider, the company maintains a secure, scalable, redundant and highly available network infrastructure, with geographically dispersed Internet Data Centers and state-of-the-art operations.

Business911 International provides comprehensive enterprise-wide expert guidance on IT Governance and Information Technology Risk Management. Business911 International certified consultants have decades of experience assisting some of the world’s largest organizations.

The Project Management Transformation: A Popular Goal ...

The Project Management Transformation: A Popular Goal: Via PublicCIO: Introducing Innovation ...

Justine Brown writes about a popular goal in many enterprises: the project management transformation. She explores the transformation at the New York City Housing Authority, which embarks on a disciplined project management process to enable more successful IT projects ...

... "The initiation phase sets out a business case that makes the ROI up front -- that makes certain recommendations as to the solution; what the alternatives, inherent risks [and] assumptions are; how possibly to procure it; what resources will be involved internally and externally, etc., said Heller. The Operations Committee must approve the project for it to move to the planning phase, which identifies project requirements, such as potential technologies and resource/cost requirements, and sets the stage for the remainder of the project, which continues through the remaining phases until complete -- assuming it meets each phase's strict entry and exit criteria. ... " ...

101 Project Management Uses for Mind Mapping Software

OK, maybe not 101, but I can think of at least six uses:

1) As a graphical way to capture goals and objectives during project initiation
2) For brainstorming solution ideas
3) To facilitate WBS planning and creation
4) To facilitate issues management in a more organized fashion
5) For brainstorming project risks
6) For capturing lessons learned throughout and after a project

Most mind-mapping software (which allows drag-and-drop functionality to sort ideas by category) is inherently easy-to-use, and allows for a quick and graphic way of sorting ideas and issues, especially when done in a group atmosphere.

Mind Manager from Mindjet is a good example, and it even exports to MS/Word, Powerpoint, and MS/Project. Check out their site below for more details...

Mindjet: Software for Visualizing and Managing Information

Managing Project Risk in Texas

US state IT departments have a complicated customer base and a wide variety of project types to carry out. You can understand why a robust set of project management processes would be important for managing them. This example of a risk management process from Texas is interesting - it is clearly laid out, covers the major activities associated with risk identification and management and gives examples of types of risks and how they might be addressed.
The fact that there does not seem to be a more recent version of this procedure than V1.0 from 2000 invites the question of how actively the process is being followed and refined.
DIR - Guidelines: Analyzing and Managing Project Risk

NASA - Warning: Projects May Be Closer Than They Appear

Here's a great case study of software projects from NASA's ASK (Academy Sharing Knowledge). It explores the fine balance between software experimentation and needing to meet the targets of a project. Some key lessons, according to the case study are:

• When tailoring a COTS (Commercial Off The Shelf) software product, you
  should recruit developers who have an in-depth understanding of the intricacies of the product.
• Establishing open communication with your customer is not only intended to
  understand customer requirements but also to convey challenges you face on the project.

Both valuable lessons indeed.

The first would seem obvious, but many people attempt to customize or integrate purchased software without having experts who have "been there and done that" with that particular piece of software and know where the mine fields are. This can be a dangerous oversight.

Likewise, many talk about the importance of communicating with the customer to understand requirements and share "good news," but it's equally critical to engage the customer in meeting challenges and risks.

In addition to the above lessons, the case study also points out three key points:

• Be sure to articulate the business need to software developers
• Understand people, not just processes and technology -- all three must be present. For intance, we must get developers to apprciate the need to schedule and budget, and we must get customers to understand risks and constraints.
• Stay out of the weeds and delegate more - otherwise you can't see the whole field. If you find yourself getting so bogged down that you can't manage the project - consider what can be delegated (perhaps including project administration).
• Given a tight target date and unknown territory, go for phased milestones.

For the full case study, read on...

NASA - Warning: Projects May Be Closer Than They Appear

Why Projects Fail ...

Via IEEE Spection Feature Article: Why Software Fails ...

Robert N. Charette writes about why software projects fail and how we waste billions of dollars each year on preventable mistakes ...

... "Most failures, in fact, can be traced to a combination of technical, project management, and business decisions. Each dimension interacts with the others in complicated ways that exacerbate project risks and problems and increase the likelihood of failure. " ...

Managing Projects with Unrealistic Deadlines

One of the most frustrating challenges for project managers is attempting to manage a project with an unrealistic deadline, especially if the date seems arbitrary. This excellent and insightful article from TenStep, Inc. (note the link to view the PDF version) explores several approaches one can take to deal with this common problem, including:

• Using the triple constraint of time, scope, and cost to make the case for adding time, reducing scope, or adding resources/cost if appropriate
• Pointing out the risks early and managing risks tightly
• Considering reducing the scope
• Aggressively monitoring the schedule and raising issues immediately
• Involving the sponsor in offering ideas for meeting the date
• Exploring other project approaches or methods that may shorten the time
  
  Read the article below for more details.
  
  Managing Projects with Unrealistic Deadlines

Project Risk Management: Critical Chain

Project Risk Management: Critical Chain: Via ACC: Acquisition Community Connection: Buffering Against Risk – Critical Chain and Risk Management ...

Article discusses project risk management techniques that link scope and time management with risk management using critical chain techniques ...

... "Network Building: Risk Identification, Avoidance and Mitigation: The usual Critical Chain approach to developing a WBS and project network emphasizes identification of dependencies. This helps to avoid risks of missing interactions of different parts of the project. Clarity and completeness of prerequisites for tasks clearly defined as dependencies helps to assure that the risk of missing necessary inputs is minimized. Definition of the deliverables of tasks from the view of the receiver and user goes a long way to make sure that the availability of those inputs is assured. " ...

Project Risk Monitoring: Milestone Tracking ...

Project Risk Monitoring: Milestone Tracking: Via Software Tech News 2-2: Software Risk Management - The Practical Approach

Practical tips for risk monitoring ...

... "Risk Monitoring: This provides timely risk visibility and resolution. Incorporate techniques such as milestone tracking, tracking of top risks, guarding against new vulnerabilities from prior fixes, and continual risk reassessment. Insist that at any one point in time the program manager, the principal investigator/technical lead, and each developer be able to state his three top risks (i.e., priorities, or watch items). These are dynamic, and as each one is resolved, another should move up to take its place. Finally, ensure that the feedback loop stays active. " ...

Software Projects: Dealing With Estimation Bias

Software Projects: Dealing With Estimation Bias: Via STSC CrossTalk: Reducing Bias in Software Project Estimates ...

David Peeters and George Dewey write about the challenges associated with bias in the software project estimation process. Risks associated with variability in estimation quality can be confronted with worst-case scenarios, clarifying assumptions, being consistently realistic across team estimates, and soliciting estimate insights from stakeholders ...

... "In spite of impressive advances in processes and tools, software project estimating remains more of an art than a science. Software projects continue to finish behind schedule and over budget, if they finish at all. According to a recent study, only 37 percent of software projects are completed on time and only 42 percent are completed within budget. " ...

Tag: Project Management