When analyzing the decision to implement a new project software to improve enterprise PPM (Project and Portfolio Management) system, user maturity levels should be a serious consideration of the new project software.
In order to make a deployment successful you must know and understand your audience:
– Who will be using the project software?
– What challenges are the users facing with their current processes and toolsets?
– What benefits are expected out of the project software for each of the user roles?
– What capabilities are needed to ensure this application will meet the user’s needs?
– Where does each user fall in organizational project management maturity?
Organizational readiness is a critical factor in implementing a new project software system and will essentially make or break your deployment success. Let’s take a look at all the areas where maturity can be measured.
For more information, download this Free white paper
Project, Portfolio Management (PPM) for the Enterprise – Whose System is it Anyway?
There is more to project software design then just defining the various roles in your organization. You must also understand the functions that each role plays in the business as well as what tools and processes are being leveraged to execute them. There are many maturity models available to help you determine where your organization and users reside in project management maturity. I tend to prefer the maturity model published by Gartner for PPM Maturity.
Maturity can be measured by the tools and processes currently in place as well as the disciplines supported by them. Again, the faster you move up in maturity, the more risks you will introduce. When implementing a new project software system it is always a good idea to start with a transfer of the current processes. For example, if a user is managing their resources through a list of projects found in an excel worksheet; transfer that same process into the new toolset. If the user expresses that the same process is also one of their core challenges, make adjustments to that process where needed but start at the same level of process maturity within the PPM application. As users become familiar with the toolset, it will be appropriate to mature their processes as well as adopt new functionality within the project software system. User readiness is crucial. Forcing your users to utilize a tool that leverages unfamiliar disciplines and processes will only result in user frustration, low user adaption and overall rejection of a critical investment. Don’t expect to implement a project software system that will leverage the same functionality for every user; instead, implement a flexible and scalable system that will accommodate all users and allow them to improve their productivity through gradual maturity progression.
It is wise to not only determine current organizational readiness and maturity but also define a roadmap to ensure your organization has a plan for improving overall maturity to gain better control and management of all project and operational investments.
Similar to users, there are multiple levels of maturity found in system capabilities. As you define the processes that are currently in place for your users, the capability maturity will also be revealed. Let’s take a look at some of the common PPM capabilities that will be defined in your project software system.
Portfolio management includes both the discipline of identifying and selecting the RIGHT projects for your portfolio as well as the ability to effectively manage your portfolio of projects once they have entered the execution phase. Although portfolio selection is critical, many organizations begin with project execution or the managing of project schedules long before they consider the benefits of portfolio selection. Identifying the right projects for your business may include processes such as determining business objective alignment, identifying risk probability, resource and cost planning, and project portfolio scenario modeling. For the execution level user, portfolio management may simply be portfolio visibility across all projects and work. Visibility into project status, resources and costs generates awareness and will help prevent unforeseen risk to maintain a healthy portfolio. Questions that will help determine portfolio management maturity may include:
– Will this project software help you manage potential projects?
– What kind of information is required to accept or approve a project?
– What is the process for moving projects from proposal to execution?
– What project and work data must be seen across your portfolio to ensure a healthy portfolio?
Projects and work will be the core of your project software system. Project management maturity is a critical factor in determining what tools should be implemented and to what level of functionality. Don’t be surprised if you end up spending the bulk of your design session answering the following question: How do you define a project? Most organizations function at a low maturity level. Maturity can be measured by the processes already in place within your PMO or across your projects. For example, are processes clearly defined or are they ad hoc? Do users use the same tool consistently or is everyone on their own when determining what tool works best for them? It is important here to understand what type of projects and work will be handled in the PPM system and how that work will be defined. Will you manage that work at the task level, the milestone level, or will projects be entered and tracked at the project level? Imagine filling out a document or project charter regarding your upcoming work. What questions need to be answered and what data needs to be defined? Once you have clearly identified the information that must be captured for all your projects, define what processes will take place to execute on them. How will you manage changes, issues and risks? The level of project detail and the depth of your processes will help determine maturity and corresponding functionality that should be introduced to the business within the project software platform.
In the last discipline area of project management you determined whether or not your projects will be detailed to the task level or will be managed at the project level only. If you determined that they will be managed at the task level, schedule management is the next necessary topic for design. This area is critical because we all work differently. Many PPM tools give you one scheduling option. This could be a point of failure for many organizations. Which user maturity level will the scheduling tool accommodate? For those that fall above or below that particular maturity level, what tool will they use? User adoption is the only answer for a successful PPM system. Every user must have the tools necessary to manage their work at their level of comfort. If I’m a Marketing Director who needs to maintain a simple list of campaigns, there is no question that I will need a different scheduling tool than a Construction Manager who needs to manage the build of a new hospital to code.
Resource management can mean many things. Let’s take a look at the various ways resource management can be applied to your project software tool. There is much more to this discipline than simply assigning work to a resource. We’ll take it from the bottom up. A task or work is put into the system and a resource is assigned. The resource goes into the system, views his/her work, executes on the work and marks it as 100% complete. Some organizations stop here in the practice of resource management, but there are many more levels to reveal. How do you know which resource is available to work on the task? How do you know if they have the right skill set? Let’s now work from the top town. A project has been defined and you need to build a resource plan against it. You don’t know who is available or who has the proper expertise but you do know what role you need. You schedule 5 developers over the next 3 months to work on this project. Now you want to see which developers meet the requirements of your project. The PPM tool must be able to accommodate your method of resource management, whether the bottom up or top down approach, or both.
Let’s move on to cost management. The following questions should be considered when determining cost management needs for your project software system. At what level do you plan your project budget: project or task? This again will help you determine where the budget data will be entered into the tool. What types of costs must be tracked? For example, do you only want to track the costs associated with resources, or also other project costs such as purchases, expenses, materials, subcontractors, overhead, etc.? If the answer to this question is expenses, you may want to design an expense form used to track expenses and apply against your project’s financials. If your organization isn’t prepared to exercise cost management at the task or work level, don’t. Start where you are now and then mature your processes as you adapt to the tool. A system that houses partial data can lead to poor decision making. How will you know what decisions are necessary when you don’t have the visibility to see where you currently are with your costs?
Tracking and Controlling
Tracking and controlling is important because it not only defines the data to be tracked but the process for how it will be tracked within the system. For example, do you want team members to supply detailed progress information about their assignments? If so, you may want to allow team members the ability to go into their tasks and enter percent complete. Then, the updates can automate back into your schedule to save time and improve efficiency.
Are you looking to include timesheets in your project software system or are you looking to integrate your current timesheet system? If you do want to include timesheets in the system you will want to make sure that it has been configured to include the proper categories needed to reflect your business needs. If you were reporting actual hours worked on a weekly basis against projects, would you complete your time entry daily or do it at the end of the week? This response is also needed to help define your timesheet configuration.
What work do you want to track? Is there a requirement to identify and track changes in scope or other issues when project status changes? If the answer is yes, you may want to define attributes needed for a change request list/log so project owners can easily adapt to those changes and adjust their costs, schedules and resources accordingly. Do you have a requirement to track project issues and risks? Is there a requirement to track other work items that need to be considered when managing your projects and resources such as service requests, action items, etc.? Again, data capture must take place for ALL work that affects your costs, resources and/or schedule.
Reporting and Business Intelligence
Now that we have addressed the main content needed for project and work definition and management, let’s take a look at some of the outputs that may be considered in your project software system design. Some questions to consider are:
– Do you have reports that you use today that are used for analysis or decision making?
– Do you currently have a requirement to generate a weekly/monthly status report?
– Do you have any standard reports required for your projects?
– What type of information would be useful when viewing project status?
The answers to these questions will help you determine what reports and dashboards are necessary to ensure you are getting the outputs required to maximize ROI and optimize value of your PPM and work management system.
As you can imagine, there are many more questions that can be asked to help you define a detailed business-specific design that is right for your organization. Other areas that must be considered in design include integration, demand management, workflow and governance and general collaboration needs. As questions are answered and more questions are generated, make sure you are considering every user and every maturity level. The level in which you capture data can vary, but ensuring that the system is built to make it easy to capture data COMPLETELY, across all projects and work, is critical for visibility and accuracy.