Getting What You Want From a PM System
Since I joined the IMF 18 months ago, much of my time had been dedicated to upgrading the project management system the team relies on for accepting job requests, processing jobs and generating management reports.
When I first saw the old system a few years ago, with a task to initiate an upgrade, it was crying for a revamp. Clients referred to it as a black box (after submitting requests, they could not monitor progress), and even the creative team struggled to see the status of a project. Another challenge was the request form; it was too generic to keep up with the evolving range of services. So when we spoke to the vendor of our system and learned that a new version was to be released, we jumped at the opportunity. What we soon realized was that this meant building a new system from scratch, as the old system was too heavily customized to convert (side note: we swore not to repeat this mistake!). It was a risk, but we viewed this as an opportunity to start with a clean slate.
Then our journey began. Following contract signature, it took us 9 months to launch the project. To avoid needing to rebuild again too soon in the future, we conducted focus groups with our clients and creative teams, analyzed the gap between the functionality we had and what we desired, documented our needs, and wrote a business requirement document which identified 42 new functionalities to be implemented. Our new requirements included on-line proof reviewing, a client portal with job status view, production file storage and many more. We learned that clients wanted more frequent project updates (even if system generated) and for the job request forms to be more specific to resemble an electronic creative brief. Mind you, balancing the clients’ wish list with that of the creative team was not an easy task.
The challenge came when we, the project team, had to learn to configure the system. And as there was no formal documentation, we wrote manuals ourselves and even managed to barter our manuals for additional professional services from the vendor. After two rounds of prototype delivery and many more change requests, we were able to launch a system that delivers most of our targeted requirements.
We made the tough decision to delay the launch by a few months in order to train our 120+ users and ease the transition. And are we glad we didn’t rush it! We are learning that users cannot be forced to embrace a system, as we are still observing “teething” problems.
It’s too early to conclude the project’s success, but we are already receiving positive responses and are enjoying increased visibility into our operations. Furthermore, we now have in-depth knowledge of the system and the ability to change it so that it can organically grow. And perhaps, that is our largest return on investment.