Part II: A Project Manager’s Challenge: Delivering a Solution That is Not in Your Toolbox

We would like to introduce a new series on the Galvin Blog in which our senior project manager, Crissy Koger, shares her approach to overcoming a seemingly common yet difficult challenge in project management. We hope that you enjoy Part II of III. In case you missed Part I of the series, click here to learn about the project and its discovery process.

When we last discussed this particular project at hand, I ran up against a predicament to deliver a solution that did not allow for the development of a fully-customized software solution due to time and budget restrictions. As a project manager, I needed to figure out how to deliver an end result that was considerate of both the client’s expectations and the project’s restraints. Because the budget was tight and the clock was ticking, I had to trust not only our research, but also my instincts, to finally select a third-party vendor that would satisfy the project requirements and deliver the right solution.

Choosing “The One”

If you recall during the discovery phase of the project, we had spent a good amount of time researching third-party sources, creating detailed documentation, and presenting options to our client. After we had narrowed our list of possible vendors from six to three, it had finally gotten to the point where an informed decision needed to be made in order to stay on schedule. There was only one that could be “the one”, so I had to bite the bullet and select a vendor.

I was able to find “the one” after disqualifying the other third-party candidates either due to lack of responsiveness or fulfillment of project requirements. After performing more research and creating more documentation, we presented the final choice to the client in a way in which we felt confident. Because the vendor we selected was an overseas company, we knew it was crucial to include in our research the differences between our company and the third party in regards to work ethic. Likewise, it was important for us to confirm this information with the third-party vendor to ensure there would be no surprises.

Fortunately, our research paid off, because not only was the client satisfied with the decision that was made, but we were able to smoothly transition into the development phase. As a project manager, it is a great feat when the discovery phase can conclude on an optimistic note.

Beginning the Development Phase

Now that we had all the building blocks in place, I felt confident that we could proceed into the development phase of the project on the same positive note, irrespective of the known challenges and unforeseen obstacles. After all, proactively maintaining a positive attitude is a key step in instilling lasting confidence in each project stakeholder. However, as any project manager can come to expect, obstacles are bound to present themselves in every phase of a project.

So far the greatest obstacles I have encountered during the development phase are simply due to the fact that (1) the deadline is close, (2) the development team is far away, and (3) the software development approach is agile. To quickly and efficiently overcome these three obstacles, I have been depending on communication, accountability, and adaptability to see me through to the end.

. . .

Obstacles in the Development Phase

A Close Deadline

This project was not only tethered to a strict schedule, but it also had a hard launch date, which simply meant that a date had been selected in which the final product would go live. In other words, the project must be absolutely completed by a certain date – no ands, ifs, or buts allowed. Once we jumped into the development phase, there was no longer any room to make mistakes or ponder if we made the right decision. This hard launch date was approaching quickly and our team had work to do.

Anyone who has ever been involved with a group project knows that communication is the key to success. When the development phase of the project began, I knew that I would need to increase the communication between myself and the project team. We relied on daily email messages and phone conferences to discuss the status of the project and to ensure each deliverable was being met on time. Despite the physical distance, this method proved effective as long as it occurred frequently. Not only did the constant communication between the team and I allow us to identify and resolve problems quickly, but it also kept everyone proactively aware of the approaching deadline. When the hard launch date hits, I am sure we will be able to say that we met our deadline gracefully.

A Remote Team

When we made the decision select a third-party vendor to handle the development, we made sure that we identified the benefits and drawbacks involved with managing an overseas company. One of the greatest drawbacks should be obvious: the physical distance. Face-to-face communication is often an easier avenue to discuss and resolve issues, because both parties are able to see and understand the project’s physical documentation, collateral, and so forth. However, these conveniences were not readily available to the project team and we had to learn to work together remotely.

From my experiences as a project manager, it is important to claim ownership of managing all of the resources involved in a project. This should be an assumed responsibility, but sometimes it can get lost in the process and can therefore result in an unfortunate round of the “blame game”. Clients do not want to manage third-party vendors – they want a solution to their problem. The client understands that I am managing all of the third parties involved and that they do not have to worry about a single thing. By assuming accountability for this task, I become the primary contact for all communications related to the project and am therefore able to manage my remote team more effectively.

Despite the physical distance, my remote team and I were able to communicate and document issues that occurred during the development process by utilizing case management software. This software allowed me to assign each project requirement to a use case, which I was then able to view its progress to help me gauge if the deliverable was to meet its target completion date. Also, this software served as a great collaboration tool for us. I was able to ask questions to the developers and have them respond quickly and provide feedback, which definitely ensured that the project stayed on track all parties were held accountable for their tasks.

An Agile Approach

Software development can be approached in different ways, one of which is referred to as agile software development. The agile approach is an iterative and incremental methodology that relies on rapid releases and a collaborative environment to produce an end result in a timely and cost-effective manner. To put it simply, the agile approach does not require that all of the project requirements be defined before the design or development (or any other phase of the project) phase can begin. The phases of the project overlap and will be revisited several times throughout the project’s lifecycle. From a project manager’s perspective, this can be an overwhelming task when you are already managing a risky project that cannot compromise on time or cost.

I did what any good project manager would do: I adapted. I had no choice but to make do with the situation and approach it like any other software development project. The discovery phase is crucial to any project’s success, which meant that I did not neglect the necessary deliverables (use cases, wireframes, etc.) required to define the project requirements. The only difference is that not all the project requirements were defined during the discovery phase. Likewise, whenever the client wanted to change a requirement, I had to reiterate the fact that once development began, any new requirement would have to be included in the next release of the software. It was also important to consider each new requirement against the project’s timeline and budget; if it did not agree, then we both knew that it was not a “must have”, but more of a “nice to have” feature.

. . .

Part III: Ending the Development Phase

This project has been a welcoming challenge from the very beginning. I was given a project that was not only outside my comfort zone, but it was also one that carried high risk, a tight budget, and a strict schedule. I greatly look forward to seeing the launch of the final product and exceeding the client’s expectations that were set forth at the beginning. Likewise, I look forward to reflecting on the valuable lessons that this experience taught me as a project manager.

Stayed tuned for Part III of the series in which Crissy discusses how the project turned out, including if and how it met its target hard launch date without going over budget. She will also reflect on how she overcame the challenges of the project and the lessons she learned through this unique experience as a project manager.