Project Management

The Business Driven PMO

Stories from the trenches and practical advice on how PMOs can more effectively support, prioritize and fund strategic business initiatives.

About this Blog


Recent Posts

What’s So Bad About Spreadsheets?

Top Five PPM Trends to Watch Out For in 2014

Insights and Trends: Current Project Portfolio Management Adoption Practices

Life after project completion: Is a project complete without benefits realization?

How Important is Adoption for a PMO?

What’s So Bad About Spreadsheets?

Spreadsheets are ubiquitous, heavily relied on by organizations to manage data and make critical business decisions. Spreadsheets are an excellent tool for independent analysis. The problem is that they are often stretched far beyond their home territory. Furthermore, spreadsheets tend to have limited scalability beyond the desk and the fidelity is constrained by the organization’s ability to invest in additional technology capability to manage its reliability.

It’s imperative to note that the goal of inputting data in a spreadsheet is not to get an answer, but to get the correct answer. Often a wrong answer is much worse than no answer at all. There are a number of features of spreadsheets that present a challenge to error-free analysis. It is extremely common for data to be added to a spreadsheet after it has been created. The augmentation of data can go wrong, rendering a correct spreadsheet incorrect. Even the most experienced practitioners, using all the armory at their disposal to prevent mistakes from creeping in as they work, will make common errors from time to time. The requirement in organizations to work under huge pressure to achieve deadlines makes the probability of error even higher. Some of these errors will be caught by the fail-safe mechanisms built in. But some will not.

Additionally, many spreadsheets take all night to compute. These computations can be complicated and commonly fail. However, when such spreadsheets are replaced by capabilities more suited to the task, it is not unusual for the computation time to be cut to a few minutes and the process much easier to understand.

Why Do Organizations Continue to Use spreadsheets?

The technology acceptance model holds that there are two main factors that determine the adoption of a technology: the perceived usefulness and the perceived ease-of-use. Perception need not correspond to reality. The perception of the ease-of-use of spreadsheets is to some extent an illusion. It is easy to get an answer from a spreadsheet, however, it is not necessarily easy to get the right answer. Thus the distorted view. The difficulty of using alternatives to spreadsheets is overestimated by many people. Safety features can give the appearance of difficulty when in fact these are an aid.

The hard way looks easy, and the easy way looks hard.

When Do Spreadsheets Go Wrong?

In a recent survey conducted by Daptiv, it was revealed that 76 percent of IT organizations still rely on spreadsheets for critical decision-making purposes. Spreadsheets are good when small amount of data needs to be managed. However, the "spreadsheet as database" is not always easy to maintain. At some point of enterprises will need specialized application capability to manage their database for managerial purposes. Research, such as that reported by Raymond Panko in "What We Know About Spreadsheet Errors", has found that most of the spreadsheets used by organizations contain errors—and that a considerable number of those errors are serious. In one case reported in Panko's research, the error would have caused a discrepancy of more than a billion dollars! Finally, academics have published studies of the prevalence of spreadsheet error and have sought to identify circumstances dangerous in the context of error and other circumstances that are regarded as safer. Therefore, unless spreadsheets are being used for single functionality, it must not be overburdened with complex calculations and codes. 

One of the most widely used tools for project management in software teams today is the spreadsheet. Although fairly cheap and easy to use, spreadsheets are extremely vulnerable to errors. They hide problems that can hinder the success and create more costs than one has planned for. Here are some of spreadsheets’ inherent limitations:

  • Consistency is hard to maintain when storing data in spreadsheets. A particularly pernicious problem with using spreadsheets is its tendency to auto format fields. In addition, there's a significant risk of messing up data when it's held in a spreadsheet.
  • It's extremely difficult to develop accurate spreadsheet models. The software development community has invested extensively in developing agile methodologies, frameworks and tools to improve the quality of software. In comparison, relatively little work has been done to improve the quality of spreadsheet modelling -- and the work that has been done has had minimal impact on spreadsheet users.
  • It's also all too easy to enter incorrect data into spreadsheets. A wrong keystroke and a formula is replaced with a static value, rendering the calculations meaningless. Another (ab)use of spreadsheets is its use in business models -- strategic planning models, forecasts, simulations, what-if analyses, etc. With limited insight into data and superficial view of results, spreadsheets should not be made the foundation for significant corporate decisions.
  • Transparency: Spreadsheets are disconnected. All feedback, ideas and requirements are stored in separate files and there is no easy way to relate them to each other. This way the initial intent behind some features can get lost and the flow of context disrupted.
  • Traceability: It’s almost impossible to manage something that you cannot track. With spreadsheets information is usually scattered across multiple files and folders. There is no easy way to get a complete view of the task in progress and/or its status. This can delay decision making and increase time to market.
  • Planning: Spreadsheets are very one-dimensional in nature. However, seeing the interconnectedness and hierarchical arrangement of all requirements and tasks is a crucial element of the planning process. It allows you to properly allocate resources, create schedule and prepare for impediments. Using spreadsheets is a tedious and error-prone task as in most cases one will need to update information across multiple files even for the smallest adjustment in plans. In addition, there is no easy way to make sure that everyone on the team/organization has the latest version of the plan and is working on the things with highest priority.
  • Collaboration: Team collaboration is the key for every organizations success, and this is especially true for geographically dispersed teams. Usually collaboration occurs over some kind of document. The most common way to share such information with other members of the team, when you use spreadsheets, is to email it. This can lead to problems like multiple versions of the same file being updated simultaneously, delays in decisions, and miscommunication. This lack of a common environment where a team can collaborate is one of the biggest limitations of spreadsheets.
  • Salability: Spreadsheets are really intended to do the analysis not to the “database”. Although we try, the more data that is in this “database” increases the likelihood that a simple error made with a typo will result in these aforementioned errors.
  • Referential Integrity: Well we have already established that spreadsheets should not be considered as a “database”. But maintaining the integrity of data relationships is fundamentally not the role of the spreadsheets.

To be fair, spreadsheets aren't the only models that contain errors. We all know that software has its fair share of bugs. But the sheer number of spreadsheets, coupled with "homespun" development, and the difficult of reviewing their logic, makes spreadsheet development the Wild West of the modeling community. If you are using spreadsheets for anything more than individual prototyping in your organization, I would recommend you to seriously consider replacing them with models that are more suitable.

Posted on: June 27, 2014 03:24 PM | Permalink | Comments (7)

Elements of a Lean PMO


People and organizations all over the world continue to embrace and adopt “Lean Management Principles” in their work. What started with Edward Deming in the 1950s and later found its way into the Toyota Production System has now made inroads into software development. You will notice that IT organizations and software development teams often talk about “Lean” software development or “Kanban” as it pertains to how they work. It is therefore essential that today’s Project Management Office (PMO) understand this old new way of project execution in order to stay relevant in today’s business climate.

Before we go any further, let us first understand what Lean is all about and whether PMOs should embrace this concept as well. Lean in a nutshell, is a set of tools that help in the identification and elimination of waste. As waste is eliminated, quality improves, consequently, reducing time and cost of production. While elimination of waste can seem to be a simple subject, it is often easier said than done. Organizations often have a difficulty classifying a process or activity as waste and often tend to be conservative when identifying/defining waste. Toyota defines Lean as the reduction of three types of waste:

  1. Non-value-adding work
  2. Overburden
  3. Inconsistency/Unevenness as it pertains to flow of work

Lean aims to make the work simple enough to understand, execute and manage, and I believe that all PMOs should strive for this. Let us now get down to brass stacks and examine how a PMO could strive to be Lean. Here are some steps a PMO could take:

  1. Prioritize projects based on business value. A project is a vehicle for change in an organization, which means that the business does not like the current state it is in and constantly evolves to move to a new state. Be willing to question the assumptions that drive any decision to change and make sure that the scope of the project is in line with the desired
    change/objective. This will help PMOs avoid/eliminate non-value-adding work.
  2. Keep the internal PMO processes simple to start with and make changes as you mature. This will help the Project Managers and the PMO director to focus on delivering business outcomes rather than following mundane procedures.
  3. Level out the workload among the Project Managers so that they can provide each project the required attention. Take the help of automation tools such as Project Portfolio Management software to help with collaboration, resource management, project prioritization, and reporting.
  4. Use a “pull” system as your project intake process. In such a system, the sponsor of the project would place an initial project request. This request in-turn would trigger a project prioritization request, which in turn triggers subsequent
    requests (such as resource request). This will encourage a “just-in-time” process and will discourage a “just-in-case” process (common in a “push” system) wherein resources are often under-utilized.

To conclude, as projects and project executions take on a lean posture, it is imperative that PMOs do so as well. With this blog I have just scratched the surface of the lean PMO concept. Stay tuned for more! In the meantime, I welcome your comments and feedback.

Posted on: September 04, 2012 03:51 PM | Permalink | Comments (0)

"Opera is where a guy gets stabbed in the back, and instead of dying, he sings."

- Robert Benchley