Sunday, April 11, 2010

Clean data pays off

Data quality projects are hard to justify. Here's some business value anecdotes to help with the next business case -- cleaner data can drive increased revenues. ...

... "With information managed more effectively, Oliver estimates that you can encourage a typical supporter to spend 25 per cent more by using targeted promotions. However, building a clean database of accurate information is the vital first step. " ...


Via The Irish Times: Data is the team player

Labels: , , ,

Monday, March 29, 2010

Operating Cost Impacts in Project Business Case

Cost transparency involves educating the governance team about the impact of today's investments on tommorrow's operating costs. ...

... "Factoring in costs of collateral impact should also happen at the project management phase as applications are being developed. While an organisation's impact metric might state that a new application for 1000 users will require five help desk people ... " ...


Via Computerworld, NZ: IT cost calculations

Labels: , , , , , ,

Wednesday, March 24, 2010

The Next Business Intelligence Project

Business intelligence is a critical investment area in many enterprises. BI projects focus on creating the data warehouse, Extract/transforms/loads, report library, and portal delivery, for example. The opportunity is in making sense of the data, especially market information that provides unique insight that you can obtain faster and more accurately than your competition. Now, that would make an interesting business case for your next BI project proposal. ...

... "Clark, like many data visualizers, believes we're on the front end of a revolution in information presentation. There's a lot of work done called scientific visualization or business intelligence graphics ... " ...


Via Harvard Business Review: Twitter Data Analysis

Labels: , , , ,

Sunday, October 11, 2009

Business Disruption Costs in Project Business Case

Emerson's CIO shares insights into the company's application portfolio, enterprise architecture, and IT project philosophy. As he points out, the business case financials should show the cost of business involvement in the IT project, so that a more realistic ROI can be understood. ...

... "People don't go and look at the real total cost of the IT project. Probably the biggest thing - and also the hardest to go and put into a spreadsheet, which is why it gets overlooked - is the business disruption. " ...


Via Wall Street Journal: Emerson Electric CIO Steve Hassell

Labels: , , ,

Wednesday, July 22, 2009

Holistic Business Case

It's better to be more inclusive in defining project costs and benefits in the initiation process. Let the CFO understand your thought process and refine from there with finance's help, especially if the business is responsible for delivering benefits. ...

... "CFOs see [a project's] budget in [its] totality. There are a lot of other costs that sometimes get left out of the IT project pitch. " ...


Via ZDNet Asia: Gartner on Speaking CFO Language

Labels: , , , , ,

Thursday, June 25, 2009

CFO CIO Collaboration

How best to bridge the gap between CFO and CIO perspectives? Well-written business cases. Balance of tangible and business-relevant measures. A functioning governance process. Staffed governing council(s). A business-savvy IT strategic story. What else? ...

... "ROI doesn't always capture the true value of an IT project, but CFOs pretty much insist on some sort of ROI calculation. Suggesting other sorts of metrics that measure the full impact of a technology rollout might get the CFO in the CIO's corner. " ...


Via CIOZone Forum, Discussion Thread: Collaboration Mechanism across CIO/CTO/CFO

Labels: , , , , , ,

Tuesday, June 16, 2009

Green Shoots from IT Projects

What will drive the recovery? Will the technology industry have a role as a leader or a lagger? Let's get cracking on those IT project proposals. ...

... "If there's good news from the Gartner study, it's that CIOs aren't canceling projects outright. CIOs report shifting more work to in-house resources and delaying capital expenditures more than reducing IT project investments ... " ...


Via Motley Fools: Technology Industry Perspectives

Labels: , , , , , , , ,

Monday, June 15, 2009

Make Business Case for Strategics

Load up your project portfolio with operational efficiency projects that deliver tangible returns. Always add a few strategic investments that speak directly to enabling important business strategies, where IT can support innovative business models or a differentiated position in the marketplace. Prove to the CFO that you understand the business. ...

... "If an IT project is neither simple nor fast, it may still get funding if you can show how it supports the enterprise’s top strategic goals. Use financial measures to make your case. " ...


Via SMART ENTERPRISE: Convince the CFO

Labels: , , , , , ,

Wednesday, June 03, 2009

Govern IT Now

It's never too late to start IT governance. ... Start developing a starter set of business cases. Recruit a few non-IT executives to join the CIO in a governance forum. ... And, start practicing the conversations. Commit to improving the experience for the participants at each governance event. It's a journey. ...

... "When companies attempt too tight of a reign over IT projects, end-users figure out ways to get around it. Not enough governance, and IT projects fail to live up to business expectations. " ...


Via Insurance Networking: IT Governance Call to Action

Labels: ,

Wednesday, May 20, 2009

Project Value Delivery

I like the idea of transforming business cases into the value delivery story with the enabling plan. We should strive for this in the information technology space. Our historical challenge is being able to identify and articulate business value in the first place. But, as we mature, planning for the achievement of value is the next goal. Project plans will not be able to end at system go-live or stabilization. Plans will have to be extended to user adoption, competency demonstration, and organizational process performance and maturity. ...

... "So, we’ve got to change the business case and make it value-focused; centred around the value proposition. Then we’ve got to make the project plan value-focused ... " ...


Via CIO Australia: The New Business Case

Labels: , , , , , ,

Monday, March 23, 2009

Business Concept in Project Proposals

Sketch your project's business concepts
Complementing quantitative information with the qualitative perspective of your project proposal could be just the edge that your project's business case needs. Think sketches, graphics, or pictures, not numbers. Team Doblin offers advice on positioning your ideas and concepts. ...

... "These qualitative sketches allow business leaders to experience the concepts on a visceral level, and complement the usual projections (quantitative sketches) concerning variables like market size, rate of adoption and return on investment. " ...


Via Doblin: Business Concept Development (PDF)

Labels: , , , ,

Wednesday, March 18, 2009

Project Financials

Expect to collaborate more with your counterparts in finance to review in-flight projects for cancellation and to develop more creative ways to finance new investments. ...

... "There is a different style of IT project evolving. People are looking for the cash implications to be less onerous on the business, but that doesn’t mean that they are shelving projects. " ...


Via Accountancy Age: Funding IT

Labels: , , , , ,

Monday, February 23, 2009

Strategic Position of Projects

IT project portfolios are currently under-review for reducing investment. Portfolio reviews are a healthy process. Visibility into the business case financials and support for the current business strategy are key inputs to enable the discussion. Exercising this (even if painful) will increase your process maturity, eventually leading to an increased return on the portfolio. ...

... "if the project really is strategic -- if it involves the executive team and will enable transformation across the business -- then it is by definition more than an IT project ... " ...


Via Computerworld: Project Portfolio Management

Labels: , , , , , , , , ,

Saturday, February 07, 2009

Holistic Project Budget

Occupy the high ground and define a holistic set of project financials --- the benefits (tangible and intangible), the one-time costs, recurring costs, and potential investments in future to further scale the business capability, if appropriate. ...

... "There are few things more distressing to a CFO than being told up front about only part of the costs involved in a proposed project. " ...


Via CIO Australia: Get Your Budget Approved by the CFO

Labels: , , , ,

Sunday, November 30, 2008

Prepare to Adapt in Your Value Chain

The business case for efficiency projects should remain on the IT agenda in 2009, especially those that share value with partners in the supply chain. ...

... "all of us should be prepared to adapt our processes and make data available quickly to work efficiently with partners and keep everybody afloat. " ...


Via : IT strategy in 2009

Labels: , , ,

Monday, November 24, 2008

Use the Cloud for Project Pilots

Cloud computing could play a role in making marginal IT investments more financially attractive or serve as an incubator before sinking investment into scalable infrastructure requirements. ...

... "For a minimal investment [using cloud computing] it is possible to prove the business case for an IT project, without the need to buy expensive hardware and software licenses. " ...


Via ComputerWeekly: Amazon cloud

Labels: , , ,

Wednesday, November 19, 2008

References for Project Proposals

Checking references, reference visits, and other external benchmarks are helpful to demonstrating to your governance team that you have done your homework with regards to outside-in perspectives. ...

... "Use reference visits to similar organisations to reassure your management. Best of all, put them in touch with their peers such as CFOs in those other companies to see how they view virtualization. " ...


Via DaniWeb: Virtualization

Labels: , , , , ,

Sunday, September 14, 2008

PC Energy Footprint

Considering a project proposal for energy efficiency in the data center? Don't forget your personal computers and peripherals as an opportunity to reduce your energy footprint. ...

... "PCs and related peripherals consumed 41% of the information and communication technology's global footprint – telecoms infrastructure, data centers, and printers consumed 37%, 14% and 8%, respectively. " ...


Via Forrester: PC Power Management

Labels: , , , , , , , ,

Sunday, August 17, 2008

Business Case Reference Material for Talent Projects

Having trouble making the business case for that next HR project? Here's some interesting reference material from IBM and partners for putting that funding request into tangible terms. ...

... "Organizations that apply talent management practices demonstrate higher financial performance compared to their industry peers. Those specific talent management practices that most distinguished financial outperformers from other organizations are understanding and acting upon employee engagement and aligning recognition and performance management systems. " ...


Via IBM: The ROI of Talent Management

Labels: , , , , , , , ,

Monday, April 14, 2008

Project Intangible Benefits Should Be Identified

It is a good practice to identify non-financial or intangible benefits when developing a business case. The ideal is when you can generate a tangible return on the investment. However, intangible benefits can be aligned with business goals and may even be able to be measured. This can be helpful when the financial return of a project proposal is at or below the hurdle rate. ...

... "Recognizing what to measure and how to measure can be extremely difficult for intangible assets/benefits. There are some common but key benefits accruing through any large IT project in an enterprise that cannot be tangibly measured. " ...


Via CXOtoday: IT Non-financial ROI

Labels: , , , , ,

Wednesday, January 02, 2008

Project Advice for 2008

Advice for the new year includes building better business cases and planning for the organizational changes needed to operate new business processes enabled by technology implementations. ...

... "If your business case can't stand up to careful scrutiny and evaluation, then it's highly likely the project will experience significant downstream problems. " ...


Via ZDNet: Five Tips for IT success in 2008

Labels: , , , , ,

Tuesday, December 04, 2007

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

Labels: , , , , ,

Thursday, October 11, 2007

Business Intelligence Business Case

A business intelligence project proposal can be challenging. Can't calculate a positive NPV or ROI? Don't despair. However, you can link the investment to reducing the cycle time of your current management reporting process ... or, you can identify the incremental value of making certain decisions that you cannot make today. Often, though, BI investments are seen as strategic. ...

... "The survey found that measuring the ROI for BI investment is more challenging that for other IT projects. The overall objective of BI is to improve company performance by putting the right information into the right hands at the right time. " ...


Via TMCnet: BI ROI

Labels: , , , , ,

Wednesday, August 22, 2007

Justify Business Intelligence Project

Struggling to justify that next business intelligence project? Try pilots and phased implementations to garner support and build investment momentum. ...

... "Traditional project planning and ROI measurements are ineffective in calculating the value of BI because calculating the potential value of unknown information is similar to a prospector digging for gold. " ...


Via CIO: Project Justification

Labels: , , ,

Monday, July 23, 2007

Business Plan Sets Agenda With Stakeholders

Insights on using the business plan (or case) to get stakeholders aligned on measureable objectives and keeping dynamic story updated. ...

... "A business plan is a way to coordinate, communicate, and collaborate with accountability and tracking. It should get all the key people on the same page. Nobody can execute a plan they don’t know about. " ...


Via How to Change the World: How to Write a Business Plan

Labels: , , , , , , ,

Monday, May 14, 2007

Project Failure: Business Case Assumptions Faulty?

Don't be ashamed if you flubbed a business case or had a miss on an IT project. Your sin pales in comparison to this destruction of business value. ...

... "In 1998, Daimler paid $36 billion in stock to buy Chrysler. Yesterday, it announced a sale in which it's putting more money into Chrysler than it's taking out. " ...


Via Washington Post: Tow Job

Labels: , , , ,

Thursday, April 26, 2007

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

Labels: , , , , ,

Monday, April 02, 2007

IT Benefit Realization: Get Started

To begin with, articulating benefits in a business case, that are achieveable and resonate with the strategic agenda of business, is a challenge. Actually realizing the benefits and tracking the progress on the benefit journey is nirvana. It takes discipline and must flex to the culture of the organization. Don't wait. Start the journey today. ...

... "I cannot underscore enough the importance of effective benefit realization practices. They can go along way toward driving improved yields of IT investments. " ...


Via Optimize Magazine: IT Benefit Realization

Labels: , , , ,

Friday, December 29, 2006

Project Proposal: Pitch the Business Case

Successful project proposals require a good pitch
Guy's partner, Bill Reichert, offers sage advice on pitching business plans to venture capitalists, investors. These same principles apply to project proposals for your investment portfolio. A concise, yet informative, pitch makes a governance session efficient and effective. ...

... "Pitching is about understanding what your customer (the investor) is most interested in, and developing a dialog that enables you to connect with the head, the heart, and the gut of the investor. " ...


Via Guy Kawasaki's How to Change the World: The Entrepreneur's New Year's Resolution: I Will Fix My Pitch

Labels: , , , ,

Monday, November 27, 2006

Right Brain Project Management

I recently re-read Daniel Pink's book, A Whole New Mind. I noticed now that it's out on paperback, the subtitle changed from "Moving from the Information Age to the Conceptual Age" to "Why Right-Brainers will Rule the Future."

The latter is probably more accessible and gets to the heart of the book. The premise is that with more technical jobs being eliminated due to automation and offshore outsourcing, we're left clinging to the one thing that computers and offshore resources can't replace---the soft skills. It's not that offshore people don't have the capacity to do this, it's just not effective from a remote location.

The books specifically outlines Six Senses that are now required to compete in today's market (I'd add that these were always needed for effectiveness, but now it's a necessity for career survival). The Six Senses we need to build are:

1) Not just function, but DESIGN (the WOW factor)
2) Not just argument, but STORY (i.e. we need to be storytellers to make a good case)
3) Not just focus, but SYMPHONY (i.e. synthesis of complex relationships vs. heads-down analysis)
4) Not just logic, but EMPATHY (incidentally, the key trait in Daniel Goleman's Emotional Intelligence)
5) Not just seriousness, buy PLAY (fun leads to employee satisfaction, which leads to customer satisfaction and profits. Therefore, Fun=$ !)
6) Not just accumulation, but MEANING

FACT (not from the book, but relevant nonetheless): Per a recent management forum of 70 business schools, many of them are requiring less quantitative courses and more leadership courses. Also, a number of organizations are now recruiting design students instead of MBAs.

The key is that the logical, sequential left-brain stuff is still necessary, but we need to compliment it with the more contextual and feeling right-brain skills. With communication being 90% of a project manager's job, I'd say this directly applies to project managers as well.

Below is a link to Pink's book on Amazon...

Amazon.com: A Whole New Mind: Why Right-Brainers Will Rule the Future: Books: Daniel Pink

Labels: , , , , , , , , , , , , ,

Thursday, October 12, 2006

Project Gates: Are Kill Points Really Considered?

Since capital is usually constrained in most organizations, are we really making the best use of our project stage-gates as potential kill-points? Are we fully considering the cost-to-completion, the probability of realizing the original benefits documented in the business case, or a declining ROI if costs escalate? We will be doing a service to our organization if we take some time to develop exit criteria and consider alternatives at the project stage-gates. There's always another project in the portfolio. ...

... "The Project Plan should have included a schedule for steering committee meetings and other key points to ensure regular tracking of project progress and release of status reports. Additionally, the plan should have identified milestones and project kill points, that is, go/no go decision points for the action of senior management, the steering committee or other authority. " ...

Queensland University: Controlling phase

Labels: , , , , , , , ,

Wednesday, July 19, 2006

ITIL Business Case ...

Evergreen offers whitepaper on the business value associated with ITIL implementation, with benefits seen in operational efficiency, customer satisfaction, and risk minimization. ...

... "The white paper references a number of data points taken from current research and enterprise IT process improvement case studies consistently documenting a 20-40% reduction in the effort required for ongoing IT operations, powered by the implementation of ITIL process improvements. The same research clearly links ITIL with strategic gains in customer service quality, accuracy and efficiency and IT risk and compliance work. The development of an ITIL strategy is also discussed and an incremental approach is recommended, one which starts with small steps but shows measurable gains quickly. " ...

Evergreen Systems Releases White Paper on Building the Business Case for ITIL ...

Labels: , , , , , , , , ,

Is the Role of the Project Manager in Jeopardy? - An Editorial

A few weeks ago, I posted a blog about the new Program Management credential from PMI. In it, I referenced PMI's definition of a program manager vs. project manager in their FAQ page.

A project manager, according to PMI, has the following responsibilities (I've put some of the key points that jumped out at me in bold):

  • Perform their duties under general supervision and are responsible for all aspects of the project for the life of the project
  • Lead and direct cross-functional teams to deliver projects within the constraints of schedule, budget and resources
  • Demonstrate sufficient knowledge and experience to appropriately apply a methodology to projects that have reasonably well-defined project requirements and deliverables.

A program manager, according to PMI, has the following responsibilities (again, I've bolded the key points):

Under minimal supervision, program managers are responsible and accountable for the coordinated management of multiple related projects directed toward strategic business and other organizational objectives. These programs contain complex activities that may span functions, organizations, geographic regions, and cultures. Program managers build credibility, establish rapport, and maintain communication with stakeholders at multiple levels, including those external to the organization.

Clearly, a program manager must be closely tied to the strategic goals and benefits, monitor the program accordingly, and have a strong connection to senior management. And I also feel that the new credential seems on the surface to set the bar appropriately high.

But I can't help but feel that, in contrast, the PMP credential is losing steam. First, there are myriad organizations virtually guaranteeing an "instant-PMP" after a crash course and some tweaking of one's background experience (although PMI is now doing audits of work experience).

Second, a project manager must, in many cases, go beyond the PMP/tactical focus and possess the same traits and skills that PMI has designated as requirements of a program manager, especially in the case of an enterprise and/or global project, such as a business transformation effort. I realize PMI's role definitions are a way to differentiate and justify the new certification and I suppose one could organize their effort into a "program" to qualify for that certtification, but in these changing times (and with greater challenges for project managers), I think PMI needs to evaluate and revamp the PMP certification as well.

When I do presentations on principle-based leadership training, I have a slide where I present what I call "The PM Challenge." I present it as a boxing match. In one corner, we have a project manager, armed with MS/Project and the PMBOK, but lacking:

  • Business Acumen
  • Leadership Skills
  • Conflict Management Skills
  • Negotiation Skills
  • Presentation Skills
  • Communication Skills
  • Strategic Intuition

In the other corner, we have the "challenger," represented by "the project," with the following characteristics:

  • Global, virtual team
  • Complex technology
  • Complex change
  • Multiple vendors
  • Offshore resources
  • Conflicting Stakeholders
  • Scrutinizing Executives

Such a project manager, without the appropriate leadership and soft skills, doesn't stand a chance. Wouldn't a person with the skills PMI describes as a "program manager" be more apt to have success?

In the latest PM Network magazine from PMI, there are not one, but TWO articles that illustrate this point. One is titled "Project Management 2.0: Project Management is at a Crossroads," by Peter Fretty. The other is titled "No Limits," by Marcia Jedd, and talks about what project managers must do to crash through the glass ceiling and elevate it from the tactical trenches.

Perhaps a start would be to take a new view of project management beyond just "executing to a set of requirements to deliver on-time and on-budget." The current tactical focus might explain the consistent failure rates of projects. One problem is that PMI has traditionally "followed common good practices in the field," which of course is what a standard is supposed to do. The problem is that common practices have brought common results, which aren't all that good. Time for an upheaval. Perhaps they need a section, apart from the "standard" itself, for "new frontiers in project management," which could outline those who are breaking the mold with good results.

I'd be interested in others' thoughts on this topic. Who knows---It just might help drive requirements for the next version of the PMBOK and/or PMP credential.

Labels: , , , , , , , , , , , , , , , , , , , , ,

Friday, June 16, 2006

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

Labels: , , , , , , , , , ,

Thursday, June 08, 2006

PMO Process Primer

Last month, I mentioned a four-part series on Projects@Work about establishing PMOs. The first installment was on defining the role of your PMO up front.

Not sure what took so long for the second installment, but it's finally here and worth the wait (maybe it's a monthly series). This installment talks about the types of processes your PMO might undertake, and offers some food for thought with each process area. According to the article, a PMO might consider:

Project Processes (including demand management, approval, portfolio management, project/application lifecycle, and risk mitigation)

Analysis Processes (including business analysis, business case development, and process redesign)

Planning Processes (including planning and tracking, and capital planning and budgeting)

Administration Processes (including methodology management, training, tool development/ownership, and knowledge management)

To date, this series is an excellent primer on PMO startups. It's insightful and obviously written by someone who has had some varied experience in PMO implementation. I'm looking forward to the remaining two parts and will be sure to post the links here.

Kudos to the author, Ted Stephens, an associate principal at Intellilink.

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

Labels: , , , , , , , , ,

Tuesday, June 06, 2006

PMO Success Story: A.G. Edwards Case Study

There's an excellent article in CIO Magazine this month showing how A.G. Edwards reinvented its PMO to bring their projects to an 88% success rate (from about 50% originally).

Some key lessons:

  • They created a 25-step project management high-level framework of just the high level activities common to all projects. They didn't inflict a detailed application development methodology and left the "how" flexible, as long as the "what" was satisfied. At a more detailed level, they used Primavera for project tracking and dashboard metrics.
  • They provided leadership training to boost the confidence of their PMs
  • They moved the project managers from the PMO to the functional areas to encourage collaboration and better align the PMs with the business.
  • They offered project planning services to assist the distributed project managers with using the new framework effectively (allowing them to use the planning tool of their choice, be it Excel, MS/Word, or a whiteboard). The 25 framework touchpoints, however, are common to all projects for cross-project comparison purposes (I assume enabled in Primavera).
  • They redefined "success" as "projects that deliver business value." This gives customer satisfaction and business value even greater priority than being on-time and on-budget (note: they still improved their schedule and budget statistics anyway).

    This is the essence of the new model and bears repeating. The customer defines success. Under this model, it's quite possible to have a project that is late and over-budget and seen as a raving sucess.
  • They tirelessly met with stakeholders in individual and group settings to offer the benefits and ask for their support. They used a subtle soft-sell approach with the "bad actors."
  • They first involved the PMs receptive to new ideas as part of a pilot and them used them to "spread the gospel"
  • They measured success rates and publicized them in quarterly reports to senior management.

These are all powerful and valid ways to make a PMO successful, and are philosophically aligned with the Service Oriented-Project Management (SOPM) model I've been developing. In this case, these changes collectively served to boost IT's credibility at A.G Edwards significantly.

Here's the full article. Don't miss the sidebar "8 Steps for Improving Project Management."

When Failure Is Not an Option - Editorial - CIO

Labels: , , , , , , , , , , , , , , , , ,

Monday, April 24, 2006

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

Labels: , , , , , , , , , , , , , , , ,

Tuesday, April 11, 2006

Project Management Ain't What it Used to Be

There's an excellent article in Computerworld about how project management has evolved in the last few years to be much more than the traditional planning, scheduling and monitoring role it used to be (in some circles anyway).

Today's project manager, according to the article, must demonstrate strong business acumen, political savvy, cultural awareness, and soft skills.

A project manager today must be confident discussing a business case and benefits with senior management, negotiating the shark-infested waters of organizational politics, leading offshore resources, negotiating with vendors, resolving conflicts, and much more.

In other words, a project manager must be more of a mini-CEO than a scheduler or team leader. The implications are that a whole different skill set is required.

Here's the full article. It's well worth reading..

The New Project Manager - Computerworld

Labels: , , , , , , ,

Tuesday, January 24, 2006

Agile Scrum Project Management; Applicable to All Projects?

I just finished reading Agile Project Management with Scrum, by Ken Schwaber, and the case is most compelling.

As we've posted here, Scrum is all about daily communication and short 30-day iterations focused on business value. No doubt it's a change from traditional project management, but it takes a sensible, pragmatic approach. As the author points out, Scrum is about "the art of the possible" and especially shines when dealing with complex initiatives (which most IT projects are).

While the book is geared toward software development projects, I found myself asking if this approach would apply to other projects, such as implementing packaged software, or even non-IT projects. I think the answer is a definite "yes." However, the first round may take longer than 30 days, depending on the complexity of the configuration and a hundred other variables.

Suffice it to say that time-boxed iterations focused on delivering some level of pre-defined business value at each iteration is the right way to go for most projects, and certainly most IT projects. Phased deliverables offer earlier payback, quick wins, and allow the flexibility of changing course in future iterations. That sounds like a win-win to me!

Labels: , , , , , , ,

Sunday, January 22, 2006

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

Labels: , , , , , , , , , ,

Sunday, December 18, 2005

CRM Project: Best Practices for Success ...

Colin Beasty synthesizes input from experts to identify best practices for successful CRM initiatives. One obvious situation to avoid, is a weak business case with emphasis on the technical aspects of CRM. ...

... "One strategy sure to cripple any CRM initiative, experts find, is leading with the technology and not a legitimate business case for implementing a CRM system. To achieve a 360-degree view of customers, CRM project leaders need to gain a 360-degree view of their own business first. " ...

Via destinationCRM.com: 11 Ways to Ensure CRM Success

Labels: , ,

Saturday, December 17, 2005

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

Labels: , , , , , , , , , , , , ,

Monday, October 31, 2005

ITIL Business Case: IT Services Management Seminar Upcoming ...

ITIL Business Case: IT Services Management Seminar Upcoming: Via TimesDispatch.com: METRO BUSINESS CALENDAR

... "TECHNOLOGY: Wednesday, Nov. 2: Making the Business Case for ITIL and IT Service Management, sponsored by itSMF LIG, 11:30 a.m., in the Garden Room at The Place at Innsbrook, 4036 Cox Road, Suite C. Speakers: Andrew Brummer and Don McGinnis. " ...

Labels: ,

Tuesday, October 18, 2005

Project Management Risk: Doing Nothing

Cot's post points out the importance of considering the risk of doing nothing when developing the risk profile of a project. Understanding, the risk of doing nothing, requires an assessment of the competitive landscape, through a SWOT analysis (strengths weaknesses opportunities and threats) or other method. Including a competitive assessment and emphasizing the market opportunity or the competition's threats can be a powerful context for positioning the project proposal and business case. ...

Project Management Risk: Doing Nothing: Via Cot's Weblog: The Risk of Doing Nothing

... "The One True Risk Theory: the primary risk is making any changes at all, no matter what those changes are. Changing course is risky. When it comes to software I tend to think the opposite: staying the same is the primary risk. " ...

Labels: ,

Thursday, October 06, 2005

Project Management Solution Ownership; He Said, She Said

Here's a humorous but insightful article in Computerworld by Jennifer Pfaff and Doug Pfaff. It almost reads like one of those typical debates that Samuel L. Jackson and John Travolta enjoyed in "Pulp Fiction", but it explores a very real issue: Who should own the business solution - IT or the business?

The one point where there seems to be agreement is that the business should own the "what" (i.e. the problem to solve and the supporting business processes) and IT should own the "how" (the technical solution). At the very least, the article makes a good case for better role definition.

One thing's for sure. Jennifer and Doug must have funny dinner conversations.

'What we have here is an IT problem ...' - Computerworld

Labels:

Wednesday, October 05, 2005

CIO Value Measurement: European Market Alliance ...

CIO Value Measurement: European Market Alliance: Alinean and Birchman Group Form Joint IT Value Measurement Venture for CIOs: Expands Alinean’s European Presence ...

Alliance in European market will drive CIO value measurement services ...

... "The Birchman Group’s proven service offering, supported by Alinean, allows the company to deliver large and tangible benefits to its clients by quickly and accurately aligning IT with business objectives, often a time-consuming and painstaking task. The Alinean ROI Analyst Enterprise has significantly improved the quality of The Birchman Group’s analysis and the time-to-delivery. The Birchman Group assists customers in gaining maximum benefit from technology investments through strategy development, business case development, program management, benefits tracking, process improvement, change management and other IT Value Management services. " ...

Partners focus on IT value measurement for CIOs in the European marketplace ...

From business strategy to successful IT solutions, The Birchman Group provides completely independent expertise in planning, executing and deriving business value from IT programs. Pioneering the IT Value Management approach in Europe and South America, The Birchman Group can assure that corporate IT spending is balanced between support and innovation, is aligned with business goals, is formulated with reference to corporate peers, is comprehensively program-managed and delivers according to fully risk assessed plans. The outcome ensures that the IT department becomes a stable and consistent business value generator. With global reach The Birchman Group has enabled blue chip organizations to realize strategic intent by building complimentary and cost effect IT strategies; comprehensively assess, plan and manage a suitable and significant portfolio of Return On Investment (ROI) and Total Cost Ownership (TCO) justified programs measured by business outcomes; and deliver these programs utilizing the highest caliber Birchman program and project expertise. Established in 2003, The Birchman Group has grown rapidly to more than a 100 employees in five countries, which reflects the success of IT Value Management as a service offering and the demand from organizations for The Birchman Group’s unique set of services and resources.

Alinean develops software tools to prove and improve the value of IT investments. The company’s founding team pioneered the concept of interactive ROI and TCO software in 1994, developing award-winning solutions for leading IT vendors and consultants. Its research methodologies and software tools are used by analyst firms, vendors and enterprises, and have helped justify billions of dollars in IT spending and derived value.

Labels: , , , , , , , , , , , , , , , , ,

Sunday, September 25, 2005

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. ... " ...

The project management transformation is a key goal of major enterprises today ...

Labels: , , , , , , ,

Wednesday, September 21, 2005

IT Project Business Case: Managing the Front-End-Load ...

Via CIOUpdate: Making the IT Project Business Case

Jeff Monteforte, president of Exential IT consulting firm, discusses best practices associated with business case preparation. This mirrors the discussions we have been having about planning and tracking of the front-end-load of IT project management which culminates in the evaluation of the business case in context of the portfolio at governance. Also, validates the process of governance / selection of the most promising candidates for business case development, given the resource investment required to generate a high-quality business case ...

... "The development of the business case is itself a mini-project and should be governed by the same investment justification process as the real project. There should be a defined schedule and budget for creation of the business case. Ideally the business case development process follows a spiral, incremental and iterative process. " ...

Manage the front-end-load of the IT project demand process ...

Labels: , , , , , ,

Saturday, September 17, 2005

Managing the Front-End of Projects; Is it Part of the Project?

There has been some good discussion as a result of my post on September 15th on the "impact of initiation and planning on the project budget." Managing these early phases well is truly a gap in the project management field and there doesn't seem to be industry consensus on whether these phases (known as Front-End-Loading or FEL) should be part of the project or not. Traditional thinking seems to place FEL outside the realm of project management, as a separate entity, with project management only getting involved once the resulting charter is established. Yet, this is odd, since Front-End-Loading plays such a significant role in project success.

The paper below, from the proceedings from the 2005 PMI Global Congress in Edinburgh (be sure to click on the link for the PDF version for best readibility), makes a good case for including FEL as part of the project. At the very least, we need a way to better integrate these strategy, conceptualization, governance, and early planning activities with the project itself.

Managing the Front-End: how project managers shape business strategy and manage project definition

Labels: , , , , , , ,

Thursday, September 15, 2005

The Impact of Initiation and Planning on the Project Budget

For those familiar with Earned Value, we know that the calculations require a baseline (which get created at the end of the planning phase), as well as actual costs.

But what about all that time spent during the all-important initiation phase (which should include some sort of conceptual planning and alternatives analysis) and the planning phase (which includes WBS and schedule development)? These happen prior to Earned Value tracking.

Typically, there will be quite a bit of time spent in these phases, and by the time the baseline is approved at the end of these phases, a big chunk of the budget has already been spent. Since we can't use Earned Value during those phases (no baseline exists yet), how can we avoid blowing our budget too early?

I've seen several approaches to this:

1) One approach is to create the initiate phase in the project schedule immediately upon starting a project. Begin tracking time immediately. Consider starting with a baseline (i.e. budget) for that phase, and tracking against "budget" just like you would the rest of the project. The problem is that it's hard to budget for this type of activity.

2) Another approach is to do the initiation work (conceptual planning, initial requirements gathering, preliminary scope and business case development, etc.) outside of the project, and begin the project with the charter resulting from that "early initiation" activity (typically just after project approval). As Max Wideman said on his site, there's not really consensus in the industry if these "front-loading" activities should be part of the project or not. Still, you'd need track the WBS and schedule development, but at least those activities are easier to get a handle on.

3) I've even seen companies not bother tracking time until the schedule has been created and baselined. All initiation and planning phases are outside of the project. Sometimes they don't even submit their project for acceptance until after the WBS and schedule have been created. Most companies want the first approval earlier, though, based on an order-of-magnitude estimate.

I'd be curious to see what other approaches may exist for controlling (or not) the time spent on the initiation and planning phases.

Labels: , , , , ,

IT Governance Common Themes ...

IT Governance Common Themes: Via CIOUpdate: IT Governance: The Solution to IT Anarchy?, Part II

Rick Freedman, Intel Project Management Practice Leader, explores common themes of IT governance ...

... "The question that IT governance asks is how these decisions are made: Are they made in an ad hoc manner, with no formal governance structures and little consistency from one decision to the next, or are they consistent and disciplined, requiring that a measurable business case be made for all IT investments, and that a feedback mechanism be in place for all initiatives so their ultimate business value can be evaluated? " ...

Labels: , , , , ,

Monday, September 05, 2005

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

Labels: , , , ,

Wednesday, August 31, 2005

Project Completion Date: When?

Project Completion Date: When?: Via NUCLEUS RESEARCH: Nucleus Research Helps Organizations Avoid Costly IT Mistakes, Potentially Saving Companies Millions ...

When is a project complete? Go-Live? At stabilization? At tipping-point of adoption? At realization of benefits? ... a debated topic. Nucleus Research, in a recent independent study, explores the top five IT mistakes that cost companies dearly ...

... "The end of a project is not when it’s deployed but rather when it’s being effectively used, which can be months or years later. " ...

When is a project complete? ...

Nucleus Research is a global provider of IT advisory and research services that provides CFOs, CIOs and their staffs with the real-world information they need to maximize the business returns from their technology investments. Its analysts blend financial analysis and case-based investigations with comprehensive technology expertise to deliver factual return-on-investment (ROI) data to organizations worldwide. The company uses an uncompromising set of processes and tools to evaluate the financial return on IT assets and is the only firm to gain certification by the National Association of State Boards of Accountancy. Nucleus Research has analyst experts across the entire enterprise software and hardware space and provides clients with ongoing advice to help with both short-term technology decisions and long-term strategic plans.

Labels: , , , , , ,

Thursday, August 18, 2005

Proof Of Concept Projects

Consider a proof-of-concept prior to developing a full business case proposal for a new project investment. Proofs have been very effective for IT projects, especially when introducing emerging technology. It should be an important first step when introducing new technology partners into the enterprise architecture. Jeffrey Bauer, Dryden Flight Research Center, provides some insights in this article ... Proof Of Concept Projects: Via NASA - Proof of Concept

... "View graphs and a lot of conjecture don't inspire people to invest in projects. Proof of concept does. Once he had our video as proof of concept, he successfully sold a $50-million program based on our low-cost (roughly $100,000) prototype." ...

Labels: , , , ,

Tuesday, August 09, 2005

Project shmoject - Just gimme a frickin issues list...

How many times have you heard this? And you know what? They may be right (under the right circumstances)! Some of the best perceived projects I've managed have been those where I had a one-page milestones list and an issues list, and communicated the hell out of the project. Simple as that.

At each weekly status meeting, after going through this week's issues, we reviewed the milestones. I asked questions like: "What percent complete are we on these?" "How much time have each of you spent on these in the last week?" "Is there anything standing in the way of meeting our next milestone, and if so, how do we resolve it?" I put together a simple Earned Value chart and management was happy. Simple, flexible, and fast - three principles of any good project.

Will this work for every project and in every environment? No. But it'll work more often than we care to admit (and this is coming from a PMP-certified, project management evangelist). Of course, we still need a business case and a collaborative effort putting the plan together. But once the plan is developed, the milestones and issues list can often take you the rest of the way. As Eisenhower said, "Plans are nothing. Planning is everything." Food for thought.

Labels: , , , , , , , ,

Monday, August 08, 2005

Information Technology Portfolio Management: Excellent Interview Mark Jeffery ...

Excellent Interview: Mark Jeffery on Information Technology Portfolio Management: Via Teradata.com -> Executive Center -> Technology Portfolio Management: Increasing ROI on Technology Investments through Information Technology Portfolio Management

... "Mark Jeffery is a clinical assistant professor at the Kellogg School of Management. His research expertise is in technology portfolio management, real options applied to technology projects, and quantifying the business value of information technology initiatives. He has 30 publications in scientific and technology journals, and has developed over 12 case studies that are used in the Kellogg MBA course he teaches on Technology Portfolio and Program Management. " ...

Labels: , , , , ,