Archive for category Project-Based Solutions

The 2009 Chaos Report – Is Project Success Really that Rare?

The Standish Group released its widely quoted report (available for purchase here) on project success in April 2009. The latest report is based on a survey of more than 300 organizations and 30 interviews. A summary of the findings is shown in the figure below.

SuccessRateGraph

The news is not very positive. According to this report the number of IT projects that failed has actually increased since 2006, successful projects are also alarmingly harder to find. Here is a far smaller and less official survey on software project success rates.

From our own experience and all the anecdotal evidence I have gathered projects are often late and over budget but they are mostly successful. In my opinion the Standish Group’s survey is overly pessimistic on the success rate of IT projects. I find nothing on the Internet that explains Standish Group’s survey approach or confirms these findings. It would be better if they provided more details as to how they assess project success and how they can backup their claim of a negative trend in worldwide IT project performance.

The report did not highlight any new reasons for the higher project failure rates. There are many more capable and highly qualified project managers today than in 2006, there are better tools, an abundance of easily accessible information on project management lifecycles and methodologies, and better collaboration between all project contributors/stakeholders. I simply cannot see how the end results can be this bad.

2 Comments

Applying Occam’s Razor Principle to Product Design – Lessons learned from our Project Management Software design experiences

Occam’s Razor principle by a 14th century English philosopher states that “plurality should not be posited without necessity” or “when there are multiple approaches to solving a problem just use the simplest approach”. Seems like such an obvious statement but so much of the products we build and use today totally ignore this principle. The following best practices are based on the mistakes we made and lessons learned in building a project management software application.

Applying Occam’s rule to product design and development could go something like this:

  1. Design features that are simple to use
  2. Provide just one way of performing a function
  3. Don’t oversimplify

1) Design features that are simple to use

If you can implement a feature using several design options choose the simpler one. However, for most product development teams choosing the simpler design is easier said than done.
Here’s why:

  • There is a tendency to try and build an all in one comprehensive solution

    Since a variety of internal and external stakeholders participate in the analysis phase, designers often keep adding complexity to satisfy the many parties and differing agendas involved. Therefore, often a product that was intended to automate a simple function or provide a simple service turns into a complicated device that can “do it all”, right out of a science fiction movie. 

  • Developers are naturally biased towards paying much more attention to handling extreme cases and boundary conditions at the expense of basic patterns of usage

    I have seen the negative impact of this firsthand at Tenrox. The complexity of software developed is increased by a factor of ten when developers try to cover all possible scenarios. Let me provide an example, a few years ago our R&D team redesigned Tenrox Project Workforce Management’s rate engine so that it could support a variety of cost and billing scenarios. When the new software was released, to our surprise, a few large customers with simple cost and billing rules reported significant performance issues with the new rate engine. After some analysis we discovered that these customers were using standard hourly rates, and yet the rate engine’s new design, which had absolutely nothing to do with hourly rates had been overcomplicated and slowed down a simple calculation that was working just fine before. Of course, the engineers went into emergency mode and had to come up with short and long term fixes to their overly engineered design. It takes considerable senior executive attention to reduce this bias and it is an ongoing battle in our product management and R&D teams.

  • Iterative reviews focused on what is missing complicate product design

    After working with our R&D team on several product releases over a fifteen year period we have identified this as a recurring pattern to avoid. Here is an example. We met about a year ago to redesign our software’s budgeting feature. The designers had come up with what they thought was a simple elegant solution that they claimed would address 95% of the requirements we had encountered. The meeting started on a positive note and everyone participated in the design review. A few people made suggestions of small things they thought were missing. Eventually there were many more ideas, new, even some commonly observed, usage patterns the designers had not considered. Within minutes the simple design was thrown out the window, and a complex multi headed beast of a budgeting feature design reared its ugly head. We all walked away from the meeting a little more tired, uncomfortable with the outcome. R&D ran with the feedback and put a few good developers to the development task. Six weeks later we were invited to another meeting to get a more in-depth view of the design, including some design mockups. The meeting was a disaster; the feature had become so complicated that virtually everyone agreed that the entire design should be killed. After wasting six weeks of development time, the designers went back to the drawing board and re-designed the feature from scratch. The second revision had fewer features than the initial design they proposed! But it was just the right combination of automation and ease of use. Our third design review meeting was an overwhelming success and the new budgeting interface was a hit.

2) Provide just one way of performing a function

As any product evolves, especially of the software type, we keep on adding more and more new functions. For example, in a version one, you can only create a project from the setup page. But based on customer feedback, by version 5, you can create a project while on a dashboard page, from the project manager summary page, from the customer page, while creating a portfolio… However, if you look at the products that are often viewed as amazingly simple yet effective designs such as the iPod or Google ‘s user interface the user is given very few choices of performing the same function. I had our R&D team hang pictures of the classic iPod with just five buttons in all their meeting rooms so they are constantly reminded of the importance of this bare bones “get it done” philosophy.

3) Don’t oversimplify

This is perhaps the hardest rule of all. Let me explain with an example. Developing a timesheet application seems pretty straightforward these days and is considered by most to be a simple application to buy or develop. That is until you get into the details of the varying department specific time tracking user interface and timesheet policy enforcement requirements, cost allocation, billing, leave time and overtime calculations, and approval processes that have to be accounted for and automated. Not to mention the complexities of integrating a timesheet with payroll, accounting, project management software, and CRM applications.  We are often faced with prospects who try to oversimplify such requirements, choose an under-powered product or do not make the proper investments, and pay a very heavy price when these issues resurface in the tail end of the implementation.

However, even if your product can and must handle complex functions, always focus on the most common use of a function. If you need to implement complex or boundary scenarios they can not impact the average use of the function.

In a future blog, I will apply Occam’s Razor principle to making IT investments.

1 Comment

Project-Based Solutions: Recommendations for Project Workforce Managers

Forrester Research Analysts R “Ray” Wang and Andy Salunga have published a new report entitled "Trends 2008: Project-Based Solutions" which is highly relevant to project workforce managers and the executives who run project-based organizations. Project-Based Solutions (PBS) is Forrester’s term for the array of software products, including Project Workforce Management, that enable companies to deliver services and projects. The full report is available here.

Here are my key take-aways for project workforce managers who seek a solution:

  • "Traditional approaches segmented by internal or
    external stakeholder orientation and product or service delivery no longer make
    sense," states Wang. Companies that have a good solution for serving either internal or external customers are doing their best to leverage their project-based systems to the other type of customer and project. Companies who are looking for a solution should consider the solution’s ability to help deliver both internal and external projects.
  • "Metrics have also emerged as a critical focus for project-based solutions. Companies continue to need performance measurement tools to help them understand how well they are executing projects and programs relative to plan." This means that companies are relying more heavily on these solutions for actionable, real-time information—not just weekly or monthly updates.
  • Wang recommends: "Align your requirements with project-based processes. In fact, some of the vendors we interviewed indicated the opportunities for smaller organizations (200-1,000 employees), particularly in the services delivery automation space, to quickly standardize their project management methodologies." Implementing a project workforce management solution gives a company a rare and critical opportunity to standardize product methodologies and many other business processes using templates and workflows.
  • Integration to, or inclusion of, other enterprise processes is critical. Wang mentions specifically "core financials, core human capital management, or other project-related systems." Companies rely more heavily on their ability to share and use the information they gather with project-based systems, but also need to prioritize IT spending for custom integrations more carefully.

No Comments

Project Prioritization and Selection: “Juggling School” for Project Workforce Managers

What if the attention and resources required by one project–the "squeaky wheel," as they say–starve another project that happens to be more critical? This happens all the time in companies that lack the right processes. Strategic projects can easily take a back seat to "pet" projects, or work that happens to be more crisis-driven.

I was recently interviewed for an article that has been published on NewsBlaze.com: "’Juggling School’ for Project Managers: Seven Reasons to Overhaul your Project Management System." This article focuses on project prioritization and selection. (There is also a chapter in the book, Rise of the Project Workforce, that goes into detail on this topic.)

In the article, I described seven major advantages to prioritizing and selecting projects using a five-step process that is described in the book. Below is a condensed version of these seven reasons for implementing processes around project prioritization and selection. Click here to read the article in its entirety.

  1. It allows you to organize your company’s best interests. Like an iTunes playlist for your projects, the project portfolio puts access to the most valuable projects in one place. Managers can compare projects, make funding decisions, and report on and analyze a collection of projects in one entity.
  2. It takes the guesswork out of project management. Implementing project prioritization and selection processes elevates decision-making to a more strategic viewpoint by aligning and assigning projects with business priorities. It also helps optimize resource allocation.
  3. It provides guidance for new projects. It helps you add new projects to your queue without misallocating resources to them. At the same time, it helps you allocate enough time and manpower to ensure quality results.
  4. Risks are assessed from a global perspective on their overall impact. New risks can be assessed more thoroughly and with respect to how they will affect the company as a whole. The steps you’ll use to organize your project portfolio will help you weed out those projects that contain too much risk to pursue.
  5. It helps you know when you have the resources and when you don’t. The system allows you to balance your resources.  Your ranking system will help you see when resources need to be reallocated, and the weighting and ranking is there for everyone to see.
  6. It is less time-consuming than juggling projects. The great thing about this system is that it doesn’t need to be constantly poked and prodded. In fact, it is important not to upset the portfolio too frequently by constant prioritization and resource balancing. We recommend you have a minor review each month and a major portfolio review once every quarter.
  7. It makes people more accountable. If a project doesn’t receive the funding or manpower it needs to be successful or if it fails for some other reason, leaders will know what went wrong where, and can address those issues with the appropriate employees. But more importantly, be sure to establish a framework for continued process improvement so that lessons learned and metrics obtained may be used to improve future project selection, estimation, and ranking decisions.

Today’s businesses–especially enterprises that manage hundreds of projects–can no longer afford to prioritize and select projects in a haphazard manner, or by allowing "pet" projects to carry the day. A company without these processes is destined to stray from its strategic vision, and lose its ability to compete.

You do not have to invest in a large new software suite to accomplish the above. There are simple tools out there that can help you automate this process; even using a few in-house developed spreadsheets and manual project value data collection is better than status quo.

1 Comment

PPM Needs the Project-Centric Approach

We received interesting comments from Philip McGuin of Atlantic Global in response to our recent series from David Hofferberth about the Project-Centric Approach.

We enjoy the debate. McGuin says Project Portfolio Management (PPM) empowers the business, but he assumes that project-centric approach is old news. Hofferberth says that taking a project-centric approach is a key stepping stone to successful PPM, and that it has not been adopted as much as we may think.

PPM and a project-centric view of the business go hand–in-hand. Unless a project centric approach is adopted, standardized and perfected, then projects will most likely fail—we have all seen the research and statistics on the percentage of projects that fail or go over budget. Granted, some projects fail because they might not have been the right projects in the first place, but more often than not, execution and management of resources are the problems.

If standardizing project management techniques and methodology is unsuccessful, then moving up to the next level of managing portfolios of projects could mean that organizations are getting ahead of themselves, and not getting to the root of the problem.

There are several associations and communities in the project management arena that continue to educate and introduce new methodologies, standards, and best practices. These groups continue to grow. Clearly, a lot of people are still working hard to perfect project management—and therefore the project-centric approach. And they must reach a certain level of maturity in the adoption of a project-centric approach before they can even entertain PPM.

PPM is a great goal for the more mature project-centric organizations, where empowerment is at the level of the business (top-down), but the first step in empowering the “top” is making sure the right approach is adopted at the bottom— in the trenches, at the foundation. Empowering the project-driven workforce with the tools, methods and best practices is paramount for executing projects successfully and for providing the “top” with the information needed to make better decisions faster.

No Comments

The Project-Centric Approach, Part 4

Projects Help Everybody to Think Strategically
by R. David Hofferberth, Service Performance Insight

In the previous parts of this series, I’ve explained how businesses who think in terms of projects have better information from which to make strategic decisions. The strategic aspect of the project-centric approach doesn’t only help management make the big decisions—it also helps workers at all levels understand priorities and efficiencies better.

Too often project prioritization and funding is done in a vacuum, with very little apparent “rhyme or reason” as to why specific projects get funded, while other, perhaps seemingly more important work, is not. The project-centric approach shows everyone in the organization the relative threshold for project consideration, and therefore individuals with perceived project needs can efficiently analyze potential work to see if it could be deemed as fundable.

This approach to business will obviously compel people to carefully consider their own work. People who work on projects are more likely to think of their work as a series of investments (of their time and effort) and returns on those investments for the company—as opposed to a stream of activity with undetermined value. As project workers, they can better understand how to minimize variances, correctly state costs and benefits, and reduce risks to themselves, the work of their teammates, and the business as a whole.

No Comments

Counterpoint: PPM and the Project-Centric Approach

In response to our series on the Project-Centric Approach, Philip McGuin makes several interesting points in his blog post, Challenging the Project-Centric Approach. However, he seems to believe that most, if not all, organizations have already adopted a project-centric approach to their business. This could not be farther from the truth. After over ten years of research on this subject, I find that most organizations, unfortunately, do not view their work as “project-centric.” Taking a project-centric approach is just the first step in running a business more efficiently and effectively. And as Mr. McGuin states, “project portfolio management” is the end goal.

But before implementing PPM there are several other issues these organizations must address. The first is to develop a project-centric approach to organizational work, and have that thinking permeate throughout the organization. Taking this step also requires organizations to look at how they set up projects, and to standardize and structure projects so that they can be analyzed to determine their overall value to the organization. At a minimum, these organizations must organize projects and determine their:

  • Strategic and tactical value to the organization,
  • Risks associated with completion time, cost or not initiating the project at all,
  • Project cost,
  • Resource requirements,
  • Project schedule, and
  • Project return on investment.

It is with this basic information (and there is certainly much more that should be captured) that organizations can begin to evaluate their portfolio of projects using PPM.

The purpose of this counter-argument to Atlantic Global’s PPM Blog is to make what I believe is an essential point: A PPM solution can only be effective after the organization has taken a project-centric approach to its business. Then, they must use the information they gather from their project-centric practices in a structured and standardized way, so that PPM technology may truly add value to the organization. Companies that believe that PPM will cure what ails them, without changing the way they approach their business, are greatly misinformed.

2 Comments

The Project-Centric Approach, Part 3

Projects Aid in Strategic Thinking
by R. David Hofferberth, Service Performance Insight

In Part 2, I explained that projects allow companies to do a much better job of prioritizing their investments. It follows naturally that the ability to prioritize work—just like prioritizing any other investment—has strategic benefits.

The detailed information that comes out of the project management process is critical for management and shareholders as well, because it shows how the organization invests resources, and how the investments align with the corporate strategy.

Taking a project-centric approach also provides the management team and staff throughout the organization with the information to show how the company is meeting its strategic goals, and other areas for potential improvement.

There could also be circumstances where the corporate strategy has changed just enough to reprioritize the project portfolio. By taking a project-centric approach to the work, executives can learn the impact the changes in strategy will have on funds and staffing, and ultimately the profitability of the organization. With this information available to all key decision makers, the organization can run more efficiently, and with greater commitment to meeting the overall goals and objectives of the company.

In my next post, I’ll discuss how the strategic thinking, enabled by a project-centric approach, helps the entire organization run more efficiently.

No Comments

The Project-Centric Approach, Part 2

Deliverables and Outcomes are Well Defined
by R. David Hofferberth, Service Performance Insight

In my last post, I explained that businesses are starting to think more and more in terms of “projects” instead of just “work.” The first key benefit of this approach is that when deliverables and outcomes are better known, the ROI on “work” is much better understood.

Prior to project approval and initiation, executives must have all of the information necessary to determine whether a project should be considered and funded.  At a minimum each project in consideration must provide:

  • Strategic and/or tactical importance of the project
  • People and skills required to complete the work
  • Project schedules with delivery dates
  • Costs with pre-determined budgets and specific times of fund allocations
  • Potential risks to the project and their associated impact
  • The probable project benefits (qualitative and quantitative)
  • A project return on investment (ROI)

This detail will help establish the framework by which projects should be considered. Executives will now be able to consider each project as part of a portfolio of work, and thus determine which projects can be funded and their associated priority and anticipated delivery date.

This information highlights gaps in staffing, financial resources, and strategy, which can then be addressed by the executive team.

In my next post, we will go into more detail about the strategic benefits of the project-centric approach.

4 Comments

Take A Project-Centric Approach To Running Your Business

Part 1: “Projects” are Hot
by R. David Hofferberth, Service Performance Insight

Organizations of all types have begun to take a project-centric approach to running their business. Competitive pressures, shareholder demands and regulatory scrutiny are merely the tip of the iceberg in explaining why this is occurring.  Executives are utilizing project management discipline to manage and control their business with greater precision. Articles printed in every leading business publication affirm that the demand for project management skills is on the rise.

This new tactic is not just about classifying work as “projects” as some arbitrary metric used to show the amount of work undertaken. It really means taking a standardized and structured approach to work, with a suite of evaluation criteria used to determine the relative importance and priority of the potential work—prior to any allocation of resources.

In the next few posts on this topic, I’ll explain some of the specific benefits that a project-centric approach has for businesses.

2 Comments