The role of Project Manager centers on following a process to ensure a project is executed successfully from kickoff to completion. But there are numerous factors that can throw wrenches into that process, so project managers need to be adept at adjusting the process to suit the particular situation.
One such situation is managing an internal project. I had the opportunity to do just that when Orbit did a redesign/rebuild of our own website. Here are the five things I learned about managing an internal project.
Due to the fact that everyone that was on the project team, including those acting as the “clients,” could recite our process in their sleep, my first instinct was to handle this project in a much more relaxed manner. I figured I didn’t have to explain every step in detail or check in as often. “They know all the common project pitfalls,” I thought. “They won’t fall into them.” I didn’t want to waste anyone’s time by over-explaining things they already knew.
After noticing some downsides to handling the project that way, such as waiting longer for approvals and providing updates too infrequently to maintain momentum, I switched gears.
In presentation meetings, the designer and I explained everything in a greater amount of detail. I walked through next steps more carefully and sent out more team emails. There definitely were some moments of “Alright, we got this, move on,” but internal projects are a bramble patch, and you don’t know the best way to pick the ripest fruit without getting pricked until you try a few methods.
In a client-service industry, like ours, clients quite obviously come first. This means that even though we set a target schedule and initial launch date for our new website project, when we got too busy with client work, our internal project slowed down. There was no need to rush through our own deliverables and deadlines at the expense of getting our clients’ work done, so we took breaks from our project when necessary.
In and of itself, this is not a problem. The problem arises when you pause the internal project for so long that it becomes difficult to pick it back up again. Perhaps team members had forgotten about or changed their minds on decisions they had reached in previous meetings. Perhaps the new deadline is now during a time of year that doesn’t jibe with the remaining project schedule. Perhaps you just need to get your project out there so you can start generating leads or making money off of it.
Our new website launched exactly two months after our original estimated launch date. While this may sound like a lot of time, in the grand scheme of things, it wasn’t a problem. There were no negative consequences to the delay, and we never had to put our own work in front of our clients’.
Daring to attempt a never-before-done feature or a distinctive, highly stylized design element is risky, especially on client projects. Unless you have explicit permission to try something new and different, you stick to the scope of the project.
When you’re working on your own project, however, there is leeway to be risky. Internal projects allow for a little more flexibility in the budget, particularly when the desired new feature is designed to meet a need, benefit ROI, and/or retain traffic.
Our old website wasn’t failing us in any way; it was a good lead machine and didn’t look dated. But one of our main goals in doing a redesign was to go from good to outstanding. We wanted to stand out as a leader, not just one of the pack. This mentality allowed us to design and implement several new features (such as this social media feed about our office culture) that, if proven successful for us, we could potentially standardize and then use on clients’ sites. Plus, trying new things keeps things interesting!
On an internal project, news spreads faster than this cat running away from its doom. After a design meeting where our project team decided to develop a fun and engaging new feature, at least half the company knew about it within a week. People get excited about things that are new and different, and it’s hard to contain that excitement to the small project team.
There is also a lot of sharing and collaboration on internal projects so that your work accurately reflects the voice and goals of the company on a larger scale, which means involving more people than a normal project might have.
Obviously, the more people that touch the project in some way, the more people that know its details. And on top of that, sometimes the physical office space doesn’t allow for much secrecy. At Orbit, our conference rooms are walled entirely with windows, so presentations are pretty much visible to whoever happens to walk by.
If you want to keep information under wraps, keep the number of people involved very small, and stress the importance of confidentiality.
When everyone in the company knows how to use and has access to the project tools, it can become like the Wild West. In the case of our website project, having thirty people with the ability to add, edit, or remove content caused a significant amount of editing distress. Edits that had already been made disappeared, consistency in style and voice started to drop, and new errors were introduced.
I had to put on my hat and badge and become the Sheriff of this chaotic town, which meant restricting access, maintaining limits, and keeping a close watch. Without that heightened diligence, outlaws would have roamed free to potentially undo or compromise the quality of the work that had already been done.
While the above items are things I discovered particularly while managing a large, internal project, the experience left me equipped to handle similar situations that may arise on any project in the future. Have you ever worked on an internal project team? What did you learn? Let us know in the comments below!