I am trying to get a buy-in for Clarity from the upper management.
I have been asked to produce a feasibility document for our new PPM system. I have identified the following features that the PPM should have. Could you answer yes or no to these? If you like please feel free to elaborate on them.
| Features and Functionalities | Clarity PPM |
| Time management | YES |
| Scope management | YES |
| Cost management | YES |
| Quality management | YES |
| Resource management | YES |
| Communication management | YES |
| Request management | |
| Program management | |
| Portfolio management | |
| Demand & Capacity management | |
| Risk management | YES |
| Procurement management | NO |
| Waterfall and Agile PM | |
| Desktop-based | NO |
| Web-based | YES |
| Analytics | |
| Custom Reports and Dashboards | |
| Prioritization and Scoring | |
| “What-If” scenario planning | |
| User/role/ department configuration |
|
| Flexible pricing options | |
| Scalability | |
| Collaboration and idea management | |
| Product backlog | |
| Application management | |
| Automated workflows | |
| Document management |
Thanks so much.
Features and Functionalities Clarity PPM
Time management YES
Scope management YES
Cost management YES
Quality management YES
Resource management YES
Communication management YES
Request management YES (Project Related Change Request)
Program management YES
Portfolio management YES (A scaleable PPM for Multiple Portfolios in large Enterprises)
Demand & Capacity management NO
Risk management YES
Procurement management NO
Waterfall and Agile PM NO
Desktop-based NO
Web-based YES
Analytics YES (This could be the USP for the PPM product. More reports and visibility provider)
Custom Reports and Dashboards YES
Prioritization and Scoring NO (Prioritization impacts the Project Schedule adversely Scoring is an eye wash)
“What-If” scenario planning YES(Extremely helpful to have this while doing the constrained and critical path planning)
User/role/ department configuration YES
Flexible pricing options NO (Out of scope for a Project Portfolio)
Scalability NO (Its a non-measurable trait. Out of context for a Project)
Collaboration and idea management NO (Collaboration complicates the Project Portfolio and Idea Management is before Project Scope definition)
Product backlog YES
Application management NO
Automated workflows NO (adversely impacts or complicates the Project Planning exercise with no or limited visibility)
Document management YES (Integrated)
Hello, Oliver,
I suggest that you focus more upon what you want to achieve in each category (e.g., resource management) than whether or not the capability exists. Resource management in (say) MS Project Server has different constraints, ability to scale, operational ease of use) than Clarity or Planisware. Please analyze more deeply than just the presence or absence of a given feature/capability.
If your organization has (say) 5000 employees you need to resource planning and time reporting, can your selected application easily handle that number? If there is an upper limit to how many resources you can use at any given time (such as 1500), you may have needless complications. If you are okay with the present number of resources to manage, will your selected application be able to handle organizational growth in five or ten years?
Say you plan on using parametric estimation (resource algorithms) at some point for short-term and medium-range resource forecasting. Demand drivers, such as complexity levels appropriate for specific functional areas, can easily grow to scores or hundreds in moderately extensive organization. How easy can you define specific drivers in a given system? What impact on performance will those drivers create? Are there system limits to the number of drivers that you can create for your company?
Let's say that you assign tasks to real people (as distinct from generic roles). How much flexibility does your selected application provide for re-assigning a set of tasks that had belonged to a given employee who has left your company (or was promoted, or died)? If you delete the old named resource (not a good idea), you effectively distort the project work already completed to date.
Another consideration in evaluating a set of capabilities is process flexibility. An application may seem effortless in demonstrations. What may not be apparent immediately is that the easy-to-use impression largely depends upon adopting the vendor's notion of business processes. You do not want to be stuck with processes that do not align with your company's way of doing business. Application adaptability to your specific processes may not have the "sizzle" of ease of use. Your project portfolio management tool needs to be flexible so that your business processes can evolve in time.
In almost every major deployment of a project portfolio solution, the vendor will be involved with initial implementation. Please keep in mind that what looks simple may require considerable proficiency and experience to bring about success in a given organization.
Look for project portfolio virtuoso performers who can make your application soar, not sales people with a smattering of technical talk. You should assess the vendor's personnel who will directly assist your initial implementation. Please devote sufficient time and resources for knowledge transfer to dedicated personnel who have commitment to your company (e.g., as employees). They are essential for successful ongoing operations of PPM.
I strongly recommend that you discuss potential applications with people who have made that application work over long periods and multiple deployments. That work takes much more time than finishing a checklist of features. It will be an investment that pays dividends when you actually deploy in your company.