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

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

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

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

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

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

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

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

Project Proposal: Pitch the Business Case

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

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

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

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

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.

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

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

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

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

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

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!

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

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

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

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

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

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

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

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.

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

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

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