I recently completed a large project for a non-profit client in the social services industry. The goal was to develop a system that would allow them to manage their case loads efficiently as their existing systems were inadequate to the task. I learned and confirmed several things by managing this project that I think you might find useful.
First, make sure you define your project with the right people. In the beginning of this project, I was working based on a series of conversations with my client’s top executive. The top executive and I were on the same page, but the two directors were confused about what the project was doing. When I re-defined the project with the three of them together, we all started working towards the same goals.
Secondly, pick the smallest team that can be effective to meet your goals. This client has a very strong team based culture. While this leads to a high degree of staff empowerment, it also sometimes means that everyone expects to be involved in every decision. Knowing that previous projects had become bogged down in this bureaucracy, we comprised our core team of the strongest subject matter experts available. As we worked through various components of the system, we pulled in additional resources where necessary and made sure all the team members were communicating well to their colleagues. This allowed us to move rapidly through requirements definition, application testing, and finally projet approval.
Third, make sure you have clear expectations for your team. This may involve teaching your team how to do their work since they may not have participated in a similar project before. Even worse, they may have participated in a similar project that didn’t function well and have developed bad habits. On our team, we stressed that the team members were not expected to know everything. But they were expected to know who needed to be involved in each piece of the project and to pull those people in as appropriate. They were also expected to keep their supervisors and colleagues informed about project progress and to use their supervisors and colleagues to help resolve any issues.
Fourth, it is imperative to get the right technical skills on board. In Billings, there is a serious shortage of experienced programmers. So we used remote programmers through a service called oDesk. I managed the requirements definition, communication with the programmers, and primary quality assurance. This ensured that the client’s staff on the team were focused on their responsibilities…the functional aspects of the system. The approach allowed me to tap into the global talent pool to find the right skills, and helped my client keep development costs under control.
Finally, consistently confirm your understandings of your projects priorities (Cost vs. Time vs. Scope). In this case, the client strongly preferred a consistent monthly cost and a full set of application features to delivering on a specific date. As a result, we moved a little slower than was technically possible. When we had to adjust the schedule, I confirmed again with the client that their preferences had not changed. In the end, we delivered within a few weeks of our best estimate (on a 14 month project) and the client was very satisfied.
Most of these learnings weren’t necessarily new to me and they may not be new to you. But looking back, they were probably the key items that made the project successful. Hopefully, they’ll help you in your next project.