What’s So Bad About Spreadsheets?

Daptiv’s Dave Blumhorst Divulges their Hidden Downsides on Wired.com 

One of the most widely used tools for project management in software teams today is the spreadsheet. They are ubiquitous and heavily relied on by many organizations to manage data and make critical business decisions. Because spreadsheets are easy to use they may appear, at first glance, to be an excellent tool for independent analysis. However, the perception of the ease-of-use of spreadsheets is to some extent an illusion. As any project manager will tell you, they are often stretched far beyond the boundaries of their functionality. With limited scalability and reliability, they are also constrained by an organization’s ability to invest in additional technology capabilities to improve their trustworthiness.

Although fairly cheap and easy to use, spreadsheets can’t often be trusted as they are extremely vulnerable to errors. Recent research found most of the spreadsheets used by organizations contain errors—and that a considerable number of those errors are serious. It may be easy to get an answer from a spreadsheet; however, it is not necessarily easy to get the right answer. Particularly if you factor in potential human data entry errors, spreadsheets can often do more harm than good. These hidden problems can hinder the success of a project and create more costs than were initially budgeted.

Daptiv’s Dave Blumhorst recently discussed the nine inherent flaws of spreadsheets, and how they’re hampering the success of PPM professionals today on Wired’s Innovation Insights. To get a better understanding of how businesses can embrace alternative technologies to avoid spreadsheet limitations, you can read Dave’s entire piece on Wired.com.

We would also like to hear about your experiences using spreadsheets. Have you run into issues using spreadsheets to manage projects in your workplace? If so, what types of problems have you faced and what solutions have you found to alleviate them? Feel free to post your thoughts in the comments section below, or reach out to us on Twitter at @Daptiv with the hashtag #SpreadSheetFailure

PPM: Everyone Gets To Play (Part 2)

In continuation to my previous blog post, this one will explain how the PPM needs of organizations drive the overall implementation process. At the enterprise level, we all recognize that different types of businesses execute different types of projects. The project portfolio for an investment bank is going to look a lot different from the portfolio at a company that designs and builds computer products, or a hospital, or a university. Even when we look at similar enterprises, we find differences in strategy, culture, and approach. Since many of these differences are the fuel for competitive advantage and operational excellence they require processes and practices which support those unique attributes.

Likewise, we need to recognize significant differences between functional areas  within the same enterprise due to the nature of the work being executed and the varying ways in which that work is done. The PPM needs for the product engineering groups are not exactly the same as those in HR.

Let’s take scope management as an example. For a company that is building something under a contract for another company, control over the scope of the project may be critical to assuring company profitability and in the most extreme cases the financial viability of the supplier organization. In this case, one would expect a much more structured, formalized set of processes for reviewing and approving scope changes and making changes to supporting contracts, payment schedules, etc. By contrast, when a department in one organization needs to communicate and manage expectations around delivery dates and costs for a sponsoring department within the same company – especially when the sponsoring department has requested the change — they may adopt a less formalized, lighter weight scope change process. In both situations changes the “what” of scope management is the same – scope changes need to be recognized, communicated and approved – but the “how” may be radically different.

We must also take into account that the approaches, tools and techniques used, even within a discipline may change over time. For many years, the construction industry used the Design/Bid/Build phases in their projects where each successive phase was substantially completed prior to the commencement of the next and each phase was executed by different organizations. Unfortunately, as a consequence of this approach many projects were plagued by a fourth phase, “litigation”, with finger-pointing and lawsuits between the parties to establish whether something was a defect in design or a defect in construction. Now many construction projects are using an approach called “Design/Build” where the work is performed and managed as a single, integrated effort. Similar changes have occurred in information technology, where new development tools and approaches have facilitated iterative and agile development of applications and business systems outside of the lockstep waterfall techniques of the past. Each of these has required new techniques for how the projects using them are planned and managed without losing the visibility needed for oversight and control of the outcome.

The most successful PMO’s and ePMO’s are those that understand the underlying goals and objectives of PPM while implementing supporting processes that are adapted  to the unique, changing needs of the enterprise, and the functional groups and disciplines within that enterprise. While this requires open-mindedness and creativity the adoption of PPM across multiple disciplines in thousands of companies is proof positive of the feasibility and be benefit to be derived from the effort. In short, despite the declaration of that gentleman at my first PMI meeting – PPM is relevant to Information Technology. And  to Finance, Marketing,  Professional Services,  New Product Development, Manufacturing, Supply Chain Management, Education and any other discipline or organization that invests in and executes projects. It also still applies to Construction and Engineering…

As a post-script I would add that since that first meeting I have belonged to PMI for many years and attended numerous meetings in a variety of other locations and chapters which were well attended by individuals from a wide variety of organizations and disciplines.

PPM: Everyone Gets To Play (Part 1)

I remember my first PMI meeting.  It was in the early 1980’s and I had just been appointed to manage a fairly large project for the Data Processing Division of a large bank. The meeting had been recommended to me by a colleague who was not a project manager herself but was married to a project manager at a large civil engineering company. I was the only person at the meeting who was not a civil engineer or construction manager and the keynote address was about building a large oil refinery in the middle-east. I should also mention that I was the only woman at the meeting and a good twenty years younger than anyone else in the room. During a break I was chatting with a couple of the other attendees and when I told them where I worked one of them observed that he believed that “real project management” wasn’t really relevant to Data Processing. Needless to say, I didn’t go back.

Fortunately while at that meeting, I joined the PMI and got my first copy of the Project Management Body of Knowledge – which came in a 3-ring binder. I read it and realized that it contained a lot of information that was obviously influenced by engineering and construction but also seemed to be very relevant to the projects we were trying to manage in Data Processing. Indeed, there were a number of others in DP, which eventually became information systems, then Information Technology, who also saw the relevance of methodically applying a set of principles and processes for managing technology projects.

People started writing about and consulting practices were built around introducing these methods into organizations as a way of improving the predictability and performance of projects, not only in Information Technology but in other industries and disciplines as well. In 1975, Thomas Wheelright and Kim Clark of Harvard first published The Product Development Challenge: Competing Through Speed Quality and Creativity which included a number of case studies and arguments for applying what are now considered standard project management processes to managing the development and introduction of new technology products. Wheelright and Clark also expanded the focus from the execution of an individual project to what they called the “aggregate project plan”, which “helps managers focus on a set of projects” and “improve resource allocation, project sequencing, and critical development capabilities” – a recognition that project management and project portfolio management (PPM) are not different disciplines but common views from different perspectives.

Organizations have also changed to recognize the role of project and portfolio management. Project Management Offices (PMO’s) began springing up as an internal mechanism for introducing best-practices and processes into enterprises, providing oversight of the processes, and maintaining and providing specialized practitioners (project managers) who understood and could effectively apply these processes and principles. And while PMO’s have tended to focused on one segment or discipline within the enterprise (most notably IT),  enterprise PMO’s (ePMO’s) are becoming more common as enterprises realize the value of providing oversight and managing the portfolio of projects from the enterprise level.

There are a number of reasons for the proliferation of defined PPM processes and specialized organizations supporting those in different disciplines and businesses. The need for transparency, common language, oversight, and strategic alignment are not industry or discipline-specific; they are the common challenges that PPM is designed to address. What is different is how these processes are applied and executed to support the unique needs of the organization, both at the enterprise and functional level. What is appropriate and effective for the IT division of a multi-national conglomerate may not be appropriate for the product development division of the same company or the IT department of a small start-up. In my next post I will walk you through what makes a successful PMO’s and ePMO’s. Stay tuned.

Top Five PPM Trends to Watch Out For in 2014

The business world is forever changing and for organizations to thrive they must be able to adopt or, even better, be an early adopter of the noted trends and predictions. All neatly wrapped up as the top strategic PPM trends for the coming year, Daptiv predictions focus on increasing the benefits of Agile, greater applicability for PPM solutions across the board, and enterprises spearheading the creation of strategic PMOs, influenced by the reliability of benefits forecasting.

Here are Daptiv’s top 2014 predictions for the Project Portfolio Management industry:

  1.  Increased adoption of PPM for integrated portfolio management: The evolution and rapid uptake of SaaS PPM has increased coordination with ancillary IT management applications). ALM (Application Lifecycle Management), Agile and ITSM vendors have been leveraging PPM through alliances, integration, and/or acquisitions. This trend began to have an impact in 2011 and Daptiv sees this to continue to play a key role in PPM’s market growth through 2014.
  2.  More PMO heads will measure effectiveness on business results: While introducing tools, using methodologies, mapping project management practices, sending project managers to training, and increasing the number of professional PMs in the organization are important metrics for a PMO head to collect and report on, they do not speak to the effectiveness of the PMO from a business perspective. To judge business effectiveness, PMO heads will determine if their work has had a positive, quantifiable effect on the business in terms of troubled project reduction, positive business results, lower project manager attrition, and faster time to market. In 2014 the practice of measuring the outputs, not the inputs, of project management will gain traction.
  3. Portfolio Management gets the attention and  funding and encourages project entrepreneurship: Daptiv sees more companies directing tight budgets toward IT and process improvement via portfolio management to get a handle on enterprise project investments. Project entrepreneurship means project managers must develop an “entrepreneurial” mindset. In 2014, this mindset will enable project and portfolio leaders to take on risks, foster innovation and focus on business value rather just looking at the traditional triple constraints.
  4. Rolling-Wave Planning (Agile): Rolling-Wave Planning is the process of planning a project in phases as it proceeds rather than completing a detailed plan for the entire project before it begins. Planning is dependent on speculation and the further out the plan the more quickly the strategy will become obsolete as conditions change. In Rolling-Wave Planning, one will plan over time as the details in the project become clearer. Daptiv forecasts rolling-wave planning to become the default approach in 2014 and expects it is here to stay in the project management world.
  5. Getting Started with PPM Benefits Realization: 2014 will see a much-needed shift of PMOs from being tactical to strategic. More formalized strategies will strategically align organization goals with the business objective of the organization, consequently delivering end-to-end benefit. Gartner estimates that less than 15% of enterprises systematically measure the business outcomes of their initiatives. Most IT and PMO organizations focus their measures on price and performance, not value. This year will move the needle by shifting the language and the focus from on time and on budget to speaking about the resulting benefits.

 

10 Ways to Absolutely Ruin your Projects

Instead of providing a list on how to successfully run a project management office, I chose a different route and set out to assemble a list of valuable information that guarantees project failure under any given circumstance. If you are a project manager or run a PMO, the recommendations you will read below are full of promise and will definitely get you into trouble.  With that in mind, here are…

10 Ways to Absolutely Ruin your Projects

  1. Start a project without a defined goal or objective:  Like a ship without a destination or a race without a finish line, starting a project without a goal is an exercise in running in circles.  No matter how much time, effort or money you through behind it, you’ll never accomplish what you set out to do because it was never clearly defined.  Then again, it’s also a great way to stay out of trouble because you’ll never know when your project is ‘moving sideways’.
  2. Run a project that is not aligned with the company’s objectives:  I know ‘mobile tech’ is really cool.  So is ‘social media’.  So let’s kick off a project to do that.  Wait a minute.  Did we ever check with our customers – both internal and external – if this is what they are asking for?   Do we know if this project help move the company’s goals forward?  I don’t know, but let’s call it “Rogue Project” because it sounds so cool.
  3. Manage a project that does not have a sponsor’s support:  Like a football quarterback without his offensive line, running a project without a sponsor to provide direction, remove obstacles, and ensure support to move the project forward is a great idea.  Please let us know how that works out for you, OK?
  4. Make a project more complex just for complexity’s sake:  If two levels down into the work breakdown structure is good, six levels is great.  It’ll show people how much more smart and experienced you are than them.  If you can do this effectively, it leads to…
  5. Micromanage your team, especially the senior level people:  Which studies show is a great way to lose supporters. Really fast.
  6. Don’t consider the benefits or ROI before you kick off the project:  Project benefits are so hard to define.  And who knows if we’re ever going to achieve them anyway.  So let’s not worry about it.  Just give me that bag of money so I can start my project already.  It’s not about value after all – it’s about working with cool technology.
  7. Recreate the wheel when starting a project:  I know my organization has done something like this before, but I’m really, really smart and don’t need the help.  I’m happy to start all the deliverables from scratch.  Or maybe this time I’ll just make up a new methodology.  Why recycle and reuse when I can just recreate?
  8. Allow your project’s scope to change on a whim:  if we don’t have a good change control process it makes the project easier.  If we learn new things, let’s quickly move in that direction.  We can call it ‘iterative execution’.  Just like a new puppy deciding if he wants to chase a ball, bark at the other dogs or have a snack.
  9. Don’t check in with the stakeholders or customer through the lifecycle of the project:  we already understand what they want, so bringing in them back in as we move through the project will only give them a chance to get more engaged and supportive.  Nah…let’s just surprise them at the end.
  10. Spend, spend, spend:  Don’t worry about budgets – they’re just rough estimates, anyway.  If we need to get more developers and fly the team out to Las Vegas for a workshop, so be it.  By the time the financial team finds out it will be too late anyway.

Hopefully the list above is taken as a cautionary tale – maybe even a checklist of what not to do.  How do you stack up against it?