Every day, we work with agencies to bring digital strategies to their clients. Almost as often, however, we find ourselves working with the agencies themselves to address their own needs. To us, the process for both scenarios is superficially very similar. For the agency we’re working with, however, this difference of internal vs external demands represent a very stark distinction.
We recently had a great opportunity to experience this first hand. In rebuilding our internal project management/internal communication/site administration system, we learned very clearly that a complex project with no one but yourselves as the client can lead to a very different set of challenges to be overcome. At the same time, however, those challenges can offer a context in which work that could never be done otherwise suddenly becomes possible.
When we started, we had a very rough idea of what we wanted. We knew the kind of functionality the system would need to provide based on both what we wanted to carry forward from our existing systems and what we wanted to change. We knew we wanted it to run on the Salesforce platform — or else be closely integrated — so as to consolidate our operational data into one place for enhanced reporting capabilities. We knew we didn’t want it to look like it was running on the Salesforce platform because of speed and user interface concerns. Beyond that, however, things were pretty much unknown.
By the way, we’ll probably share much more about this system in the future. It’s a pretty powerful and complete tool, and merits a much more thorough writeup about how we created it and what our plans are for it. Stay tuned..
We’ve done a good deal of internal work before—mostly centered around our website—and had been burned in the past. After all, how can you accurately plan and price such an open-ended proposition? If this had been an external project, where all of the work is accountable to the paying client, this kind of initial ambiguity might have been a deal-breaker. In those cases, we would have broken the project into discrete stages, including an initial “consulting” phase. Which is exactly what we did here. In fact, we treated this entire project in much the same way we would any other. This might sound obvious, but that subtle difference in approach is easier said than done.
1. Define your “client”
Its important to treat this type of work the same as you would a “real” paying project. In fact, because its not paying, this becomes all the more important. The first step toward thinking about things in this way is to frame the work to be done with an ultimate client in mind who we (well, I) would be accountable to.
Knowing who I was building for helped to give context to decisions that would otherwise be abstract. It can dictate where to focus your attention. In more than one case, it determined which feature would ship in the initial phase of the project — and which would have to wait.
2. Be serious about the schedule
When all the accountable parties on a project are internal resources, it can be easy to “slip” with the original schedule, with other work being deemed more important. When this happens, make it a point to seriously re-address the project schedule, taking into account the delay. Adjust the overall timeline, and the forthcoming discrete stages you had planned, paying particular attention to how this might impact other internal team members working on the project with you.
3. Track “expenses”
Constantly assess the bottom line of the work you’re doing. Use whatever methods are in place for evaluating client work, and treat the results the same. You likely had an agreed-upon “number” for the internal investment — if this changes, or looks like it will be exceeded, perhaps reexamining the entire project is a good idea.
4. Be a forgiving “client”
One definite advantage of this kind of project is that you and your team have the final say. Adjustments to the project scope, and all the tough decisions that go along with that, can be made with all of the above information readily available to guide you. If you’ve planned the project from the start with clearly defined requirements in mind, this should actually be easy to do whenever a delay or complication arises.
* * * *
All in all, our internal project went pretty well. We were only six months behind schedule, due mostly to breaks in the production schedule that made it necessary to shift resources to other, external projects. The initial launch contained all of the critical features — and a surprising amount of “nice-to-have” stuff, too. There is certainly a “Phase 2” coming up. It’s got a feature request list that gets bigger by the day, but it’s nowhere near as extensive as I think we anticipated it to be. Perhaps most importantly, we didn’t kill each other in the process. Which, at the end of the day, is really all the matters.