Project Management = Relief + Results

August 2015


The problem

The Division of Information Technology (DoIT) Financial Management Systems (FMS) team had a problem. An upgrade was necessary to provide a stable foundation for critical financial modules like Contracts, Grants, eProcurement, and Project Costing. But in order to save money, we had to spend the time and we had to do it fast: the upgrade had to be finished in just months, by May 2015.

In November 2014, Sally Betz, DoIT’s Associate Director for ERP Applications, took on the role of project manager. This was the way we’d always done it:  project management was a manager’s job and if that meant operational work suffered or managers worked nights and weekends, well… that was that. This time Sally had an option. DoIT was starting up a Project Management Office (PMO) and would soon have full-time project managers to devote to these campus-wide efforts. Even knowing this help was available, Sally said it wasn’t an easy decision to ask for a project manager: “I had to admit I was under water.”

After the winter break, John Kearsing became the project manager and Sally stepped into the project sponsor role. Often assumed by directors or others even higher in an organization, the project sponsor is a highly active role that continually looks for strategic opportunities, resolves staffing shortages, and helps to ensure that funding is approved and available. Relief was immediate. “John was a quick study for PeopleSoft,” said Sally. “He was good at looking at alternatives unemotionally, even when project team members had a hard time doing so.” More than that, John took on the responsibility of facilitating team meetings, dogging people for deliverables, identifying and managing project risk, and ensuring there was no project scope creep.

 

 

 

 

DoIT was starting up a Project Management Office (PMO) and would soon have full-time project managers to devote to these campus-wide efforts.


Who is this scope creep?

Meeting the May 2015 deadline meant making choices about what to do and perhaps more importantly, what not to do. As any good project manager would do at this stage, John created a scope document, which Sally recognized as a real turning point for the project. A document like this is more than just its content: in collaborating with team members on the document, John gained their trust. Sally said one could see the shift in project team members now looking to John, instead of her, to guide them through the rest of the project.

Enforcing the written, approved and signed scope document was a huge part of the project success, said Sally.  It controlled the direction of project communications and leveraged the decisions that the project team made as the May deadline drew near. So many times we hear about project teams added work that might be technically “easy” to add, but can throw in hours of user testing. This scope creep can kill a deadline. 

 

 

 

 

Sally said one could see the shift in project team members now looking to John, instead of her, to guide them through the rest of the project.


Don’t guess, test!

Sally had identified a risk early on: the focus on unit testing a single module for a single department might not leave enough time for end-to-end testing that is so critical for integrated systems like PeopleSoft. With Sally’s early guidance, John set up and facilitated a walk-through meeting to nail down the process and schedule for end-to-end testing. He guided the technical and functional experts through this work, even though he wasn’t a PeopleSoft expert like Sally. And even though the content of the meeting was important, this was another example of the focus shifting from Sally to John and an implicit recognition that Sally trusted John to take the reins.

As the technical and functional experts walked through the financial processes, they discovered ten integrations where units have to work together. The exchange of institutional knowledge during this meeting was especially beneficial because there had been turnover in financial management systems positions. 

 

 

 

 

. . . this was another example of the focus shifting from Sally to John and an implicit recognition that Sally trusted John to take the reins.


Lessons for next time

  • Trust and communication are essential to project success. Studies indicate more than 50% of projects are at risk due to ineffective communications, but many organizations still admit they’re not placing enough importance on project communication. John admitted that the communication needs were enormous: scheduling meetings, weekly reports, and daily emails may not be difficult, but they’re time-consuming and often set aside when time runs out. He knew he couldn’t falter in this area and retain the trust and commitment of the project team members. He and Sally even added more time to their week, meeting before every team meeting to make sure they both agreed on what needed to be accomplished.
  • A project manager need not be a technical or functional expert.  Project teams are full of experts. Like any good artistic director, the project manager’s job is to engage with the talent and ensure their success.
  • Signatures are powerful things. Formal documentation kept this project on track to finish and getting signatures on documents made the team members’ commitments clear.

With this upgrade, many DoIT technical staff and functional colleagues got a taste of formal project management for the first time. But it won’t be the last. Many of NIU’s cost-savings financial projects are due to start in the next year and these same people will come together again to deliver value to the entire university.

 

 

 

 

A project manager need not be a technical or functional expert. Project teams are full of experts. Like any good artistic director, the project manager’s job is to engage with the talent and ensure their success.