Summary
Enterprise project management (EPM) solutions exist across a broad range of functions. Many EPM projects fail because they try to implement too much too soon – missing a great middle range of essential project and portfolio management functions that are commonly sought and easily implemented using tools available for the Microsoft SharePoint 2007 and Project Server 2007 platforms.
This article outlines a framework for classifying how your enterprise manages projects, and how it can evolve and mature over time. This is the first in a series of articles that will show you how to adapt your immediate needs to a range of available solutions in the Microsoft framework, particularly:
· Out-of-the-box SharePoint 2007 [both MOSS and WSS]
· Third party ISVs extensions to SharePoint, such as Brightwork and Bamboo Solutions
· Microsoft Project Server 2007 and Project Portfolio Server 2007
Although covering all EPM vendors is beyond the scope of this article series, the concepts and practices outlined here are applicable to many enterprise and vendors, not just Microsoft platforms. Our goal is a phased approach to highly successful EPM rollouts and adoption.
Background
Every business has projects. Some projects may be simple, one person endeavors that last a day or two. Some projects may also include dozens or hundreds of contributors, distributed across multiple countries and run for many years.
When businesses and projects are small, project management and tracking is usually informal. However, at some point, businesses and their projects become too large and two dynamic for casual management.
It’s very common in larger firms, at some point in their evolution, to run out and buy, or build, some sort of centralized project management system. Enterprise project management systems are sold by a wide range of vendors, including Microsoft, Primavera, HP and Oracle. Many of these systems are large and complex, offering more functions than can easily be digested and learned all at the same time. Without a roadmap of how your organization will develop a more mature approach to project management systems, many of these implementations are doomed to failure.
Boiling the ocean
A fully realized, integrated deployment of Project Server 2007 and Project Portfolio Server 2007 can include:
· Centralized project tracking database
· Standardized project SharePoint workspaces for document management
· Issue and risk management
· Project status reporting to stakeholders
· Integrated project scheduling, cross project deliverables, task assignments and progress management
· Centralized employee timesheets and resource pool; resource utilization and forecasts
· Business intelligence solutions leveraging SQL, SQL Server Reporting Services (SSRS) and Analysis Services for automated report distribution and self service report design using Excel, Report Designer, dashboards, Visual Studio, KPIs
· Financial integration with line of business accounting systems
· Portfolio-level budgeting and project approval based on enterprise business drivers
That’s a great list of features. But too often, ALL of these functions are implemented out of the gate. For example, it’s confusing for most users if they don’t see a difference between an issue and a risk. Similarly, first time users have no automatic, intuitive understanding about selecting Microsoft Project plans or SharePoint task lists to capture scheduled work and assignments.
To complicate matters further, many organizations are hoping, in vain, that a tool alone can drive a standardized process. For example, a financial service firm wanted to centralize the process of initiating new projects, but hadn’t yet defined what a project was in the first place nor who was allowed to request and approve them. For a while, “projects” were being established that had no clear budget or sponsorship, leading to questions about when each project should have its SharePoint team site created, or why the system was automatically creating sites for projects before there had been any executive review. However, once the approval process and workflow was established and accepted, it was straightforward to map the technical side of creating a project in the system to the business workflow. And the bigger success was that unapproved projects no longer incurred any expenses.
Why bother?
In my experience, here are some of the reasons (right and wrong!) businesses adopt EPM solutions:
· It’s too hard to find all the documents for all the projects
· Need to know who’s assigned to which projects
· Trying to project headcount needs for next year
· We want to be able to show our internal clients what we’re working on for them and be able to show a red/yellow/green status
· We need to understand how the different due dates of different projects line up
· We want to track budget vs. actual expenses for each project
· We’ve outgrown the limitations of using file shares to link our project plans
· We bought it because it was the next suggested upgrade, so we need user adoption
· We want to publish project schedules
· We want to streamline the process of getting task updates from remote users who only have a handful of tasks spread across a wide range of projects
· Need to send updated status reports to project sponsors
· Want to make sure only project managers can update a project plan
· We are ready for enterprise project management because the software has been installed for all users. [My personal favorite!]
Function-first approaches to EPM implementations miss the point. Successful EPM implementations share two common traits:
Goal oriented. Asking users to input a lot of data that doesn’t generate any meaningful results is a waste of time and a terrible approach to information management. EPM implementations need to understand what data is required to support essential system outputs (screens and reports), and pare down their interfaces to streamline data collection and maintenance. Best practices around enterprise systems (not just EPM) include some provision for data quality. Increases in data complexity lead not only to an increase in data maintenance but also in quality assurance, audits, etc.
For example, an investment management firm made an initial rollout of Project Server that included extensive use of detailed tasks and tracing of metrics around task/milestone variances from original baselines. Although these had been tracked historically in legacy internal departments, there was no active sponsor, internally, who wanted to review this data. Nonetheless, tracking this data across the entire portfolio of projects became a source of frustration because of the time involved as well as additional work required during development, quality assurance and testing.
In addition, they had deployed functions to allow for resource modeling and forecasting – in short, to allow project managers to look at future resource allocations and reassign work to avoid over allocation bottlenecks. However, this was not a capability that was prioritized by management. Moreover, most of the “over allocation” was due to overestimates for task-level efforts. In my experience you need to make sure the task lists and scheduled are complete and accurate well before making decisions based on that data.
The bottom line, again, is to understand what you want out of the system, and define your data structures to match.
Process aware. It bears repeating – the success of any large enterprise rollout is directly proportional to your willingness to adopt the system’s implicit workflows and processes, or your ability to adapt the systems functions to match your own flows. If you have few processes defined but will adopt whatever the tool offers, you’re all set. However, if you don’t have a project risk management process and you don’t like the one in your new system, it’s not going to work unless something changes. It’s even worse if there are internal disagreements about what the process “should” be. The system itself cannot foster agreement. To be successful, understand what processes you already have, and what you’re capable of adopting, realistically, over a 12 month horizon.
The framework.
So you’ve completed your initial SharePoint rollout. You’ve transitioned a lot of legacy content to shared, web based document libraries. And you’ve set up some SharePoint team sites for some of your most important projects. Now what?
Getting a handle on your organization’s projects is one of the most common goals expressed by enterprises that have begun a SharePoint rollout. Microsoft offers a wide range of solutions on the SharePoint and Office platforms that address project management needs throughout the spectrum.
However, many organizations struggle with the pace and scope of change when they try to progress too rapidly down the evolutionary cycle.
Today, I'll introduce you to some key concepts to remember in your organization's project management evolution. It's important to assess your current state, as well as a timeline for future improvement BEFORE mapping your goals to specific toolsets. The key takeaway is that out-of-the-box SharePoint provides strategic capabilities that provide real value quickly.
Success requires a searching and fearless inventory of where you are. You also need to be willing to accept that progress, not perfection, is your goal. Look at the spectrum, and plan for how to move up one or two levels at best.
The Microsoft approach.
Microsoft views EPM evolution as proceeding through four distinct phases:
· Basic
o Standalone plans
o Standalone plans, issues lists, risk lists, and project reports
o Collaboration via file sharing, public folders/FTP sites, and e-mail
· Standardized
o Project templates to reduce set-up effort
o Use Outlook and Excel to manage issues , risks, and individual tasks
o Automated task distribution to personal task lists
· Rationalized
o Integrated project tasks and calendars
o Notifications on tasks, issues, and risks
o Time tracking and approval workflows
o Automated accurate reporting
· Dynamic
o LOB data available in workspaces and portals
o Workflow-based life cycle management
o Online help and training
In my opinion, this includes most of the right components, but may be a little aggressive (e.g. automatic distribution of tasks to personal task lists is fairly sophisticated.) In my experience these are the six level of EPM evolution:
· None
· Tracking
· Collaboration
· Planning
· Management
· Portfolio
Please keep in mind that these are only guidelines. Few organizations will match these descriptions perfectly. For instance, you may use some sort of centralized issue management but otherwise have only simple project tracking systems, such as an Excel spreadsheet. Decide honestly where you are on this scale. Then look one or two steps to the right, and understand that should be your target as your grow into your platform. In the end, the goal is to understand the wide range of features you may be able to adopt simply with the tools at hand, and to defer more complex aspects of EPM until your organization is ready.
At the same time, the most advanced levels of EPM evolution can be the most difficult to achieve, and are often not appropriate for some organizations. Smaller firms may not have sufficient scale to use resource capacity planning and comprehensive project selection and optimization criteria. At the other end, Fortune 500 firms may develop incompatible sets of criteria and needs across multiple business units, making the vision of integrated enterprise project management more difficult and less relevant.
The Six Stages of Project Management Evolution
Most organizations begin here. Usually, there are only one or two people working on a handful of short term projects. Using no systems at all is appropriate so long as communication is highly available among all stakeholders (there may be only one or two) and relevant information is easily remembered and documented. However, there is obviously no effective control of projects at this step.
Tracking – Simple tracking systems to define list of active projects, shared folders for documents
This is the first step for many organizations – answering the question “what projects are we running?” The common tools used at this step include spreadsheets, small databases (e.g. Access) and simple SharePoint lists. Collaboration is usually via email and file shares. Defining and agreeing to list of projects is not as simple as it sounds – opinions vary on how large a scope of work must be before calling something a “project”, or whether related phases of work are defined as separate project or elements of larger one. This makes this level of growth a significant milestone.
Problems seen during this stage can include finding the right version of a related file, locating people assigned to a project, and getting details on task progress for the individual components of a project plan.
Collaboration – Web-based collaboration for project teams on tasks and documents.
For many organizations, moving to a web – based intranet for project collaboration is the next stage. At this point, the EPM solution starts becoming a means for performing and collaborating on the project, instead of just listing information about the project. Web based task lists, SharePoint team sites and document libraries, cloud-based information exchange and shared Microsoft Project plans are all common attributes of “Collaboration”. Tradeoffs at this stage may include non standard approaches to defining project tasks, phases, or resources – one project may use named resources, while other projects may use generic assignments or none at all, for example.
Planning – Standardized maintenance of project plans, tasks, resources and schedules.
This stage is often, but not exclusively, found in firms that have developed a Project Management Office (PMO) function or other controlling entity. Both Project Server and SharePoint (with our without ISV toolkits and customization) can be effective platforms for this stage. This is appropriate for organizations that have deployed multiple project managers as a core capability, and have outgrown the ability of a single oversight person to keep tabs on all project managers’ activities and updates. It’s important to keep tight controls on overall complexity, since project staff and stakeholders may be several levels removed from the core project management and service delivery functions at this point.
Management – Financial management of project activity across multiple projects; centralized issue and status reporting.
At this stage the EPM solution becomes the vehicle for delivery of comprehensive real-time metrics about spending, issues and status at project and portfolio levels throughout the organization. For Microsoft-oriented enterprises, SQL Reporting Services and SharePoint based dashboards are common. Again, EPM solutions must keep tight reins on overall complexity, and capture and deliver only information demanded by their internal customers and stakeholders. Be market driven! If you turn on every function in your initial EPM solution, you may be using a “Management” level tool in a much less mature organization. However, you should be smart about using some of these features, such as issue tracking, if appropriate even if you haven’t yet rolled out financial integration, for example.
Portfolio – Formalized project approval; detailed resource planning, capacity, and optimized demand forecasting.
This is the most sophisticated, comprehensive level of EPM solutions. Data collection and aggregation becomes seamless, and swivels easily among historical and forward looking views of information. Most top end EPM systems can support these functions, although the costs of implementation are comparatively higher. In my experience, few organizations achieve this stage of evolution, and many firms have no real need to evolve to this level. However, firms that do get to this stage have developed the capability to optimize their selection and allocation of project investments, and are able to engage in sophisticated resource demand modeling and optimization for a highly efficient approach to project execution and management.
Conclusion
I’ve outlined six stages in the progressive evolution of enterprise project management systems deployment. Organizations can use this to help plan for future expansion, or pare down their functionality to match their maturity level. In coming articles, I’ll outline how to optimize your investments in SharePoint, Project Server, and third party tools to deliver efficient EPM solutions throughout the “sweet spot” of this taxonomy: Collaboration, Planning, and Management.
