A case study of what users want in project management software
Pawel Wieckowski’s opening slide for his talk on user requirements. GlaxoSmithKline presented a case about their project software deployment at Gartner PPM & IT Summit earlier this year.
He stated that they had already defined who would use this tool. He stated that users could be classified into one of these categories:
Project management in the community
Project Management Office
The whole company
He said that a PPM tool was not just for the PMO. It is also available to the wider business community. They had to balance user requirements, technology capabilities, business requirements. He stated that the key to success is finding the right balance and that everyone will be satisfied. It’s not an easy task.
They also explained why they wanted to invest, and why it was important. GSK needed a PPM program to consolidate all of their data and create a single repository. They wanted to empower and support the project management community.
Pawel explained that the dilemma was whether to go big, or change their approach. They decided to start small. They decided to first roll out their solution, then refine it and optimize later. They also used a unique approach for refinements. The team collected enhancement requests from users and asked them to vote for them. This allowed users to decide the priorities for enhancements.
Pawel Wieckowski, presenting in Gartner’s PPM & IT Governance summit in June 2014. Next steps
The company now has a tool that allows it to plan and execute its investments. It is now three years old. Pawel explained that the main improvement was to close the gap between corporate financial planning and actual company finances. The complex structure of the business combines parts that provide solutions and parts that finance projects. One project could be funded by many sub-companies, countries, departments, and countries. The PMO wanted to be able to see the effect of a project on one of these countries or companies.
The company wanted projects to be linked with their capital and operational plans. The team created a map of the organisation with high-level aggregated spend performance. The team was able show the benefits and disadvantages of projects and where they failed. They also forecasted costs at completion and actuals. They also created high-level financial plans that can be adjusted and adjusted to suit their needs. This comprehensive approach allows you to see projects as investment spending.
One of the most important features of the software was its ability to display a list of prioritised projects. The company’s maximum spending limit is called the waterline. It is clearly indicated on the project listing and clearly identifies which projects will be funded. Pawel explained that this is helpful for project forecasting and difficult conversations between project sponsors.
This does not require any fancy software. Every PMO should have a list of projects it can fund and a pipeline of projects that it would like to finish next. To be able to prioritize or change priorities, you need to see the entire project list.
Pawel stated that his team had made many modifications to the software while working alongside the vendor (he didn’t reveal who it is or if I did, it wasn’t written down) to make the solution exactly what they wanted. He suggested that everyone should do the same and add new features, even if they’re not currently available. He suggested, “Don’t be afraid of improving your tools.” “PPM vendors will soon be available.”