Recently, I was having a conversation about project management with a client, for whom we are building an enterprise Kentico-based web application. I have had this conversation many times during my career, sometimes in commiseration, sometimes in the middle of a heated dispute over development timelines, schedules and budgets. This particular project has been occupying several Kentico custom web application developers for about nine months. The client said to me something like “This was our first big custom software development project. Our project managers and executives think that we should be able to set out the roadmap, resources and timelines ahead of time and just follow the plan. Software development has been nothing like that.”
This anonymous client was exactly right. My previous post, “Why Custom Software Development is Not Like Auto Repair”
goes into some detail on the specific differences of analogy between projects we’re accustomed to and software development. However, this client was getting at something else as well: communication. Clients come to Bit-Wizards for many things – sometimes because we’re a well-known expert Kentico Partner, sometimes for our expertise in software development and integration regardless of platform. But clients are also looking for our expertise in managing software development projects, and specifically in communicating the project’s progress along the way to their own internal and external stakeholders.
There have been a lot of books and articles written about software development project management. These cover a lot of detail about what goes on in a project management meeting or throughout the overall process. I’d like to focus instead on one important factor, which is regular client-vendor meetings during the project. In particular, I’d like to give some outcomes and benefits of high-quality meetings from my experience. If your meetings are well structured along these lines, you might even wind up with excitement about the meetings rather than dread (Well, ok, realistically let’s just shoot for participants not actively sabotaging the meeting out of frustration!).
At Bit-Wizards, one thing we do – and do well, if I do say so myself – is develop a real partnership with our clients. Just talking regularly naturally leads to a connection between individuals that strengthens the relationship between companies. As the relationship continues with frequent interactions, we can build on the shared experience of the project and grow the relationships into shared understandings of each other’s professional and personal lives. That helps us share the purpose of the project together, and think on each other’s terms. Every time, we’ll start to see ways that each company can mutually benefit by new projects. And before you get cynical on me and call this nothing more than sales farming! When a successful partnership is built between clients and vendors, the vendor wants to see the client succeed more than just scoring the next big project sale.
Getting down to more tangible outcomes, scope management, is a high priority for each project management meeting. By meeting regularly, everyone should become more familiar with the details of the project scope. These regular meetings benefit both parties because scope changes become evident more quickly as the project is better understood. I used to dread identifying some feature as a change to a project because I thought I wasn’t giving the client what they wanted. Instead, I now see change management as protecting the client’s original goals and desires, because it’s easy for anyone to miss the fine contradictions with the original plan. Every project will change in its details as it proceeds. Sometimes these can be cost-neutral and just need to be documented. Other times, a change order is required that affects budget or timeline.
This process of change management intimately links with the need to expose unknowns. In a software development project, the only perfectly-defined scope is the system itself. The plan always has unknowns that must you explore – known unknowns and those sneaky unknown unknowns. By fully participating in regular meetings, stakeholders will identify assumptions they’ve made. With the right format and environment, the participants will bring up to the group when new information is challenging their assumptions. When meetings are frequent enough and productive enough, most of these assumptions will be caught before they are set into the software code. When this happens, more changes can be cost neutral by virtue of the six-one-way, half-a-dozen-another principle, instead of being costly because they are revisions.
Agile Goals and Timelines
People just function better when we can see something tangible in front of us. That means vendors should prioritize putting things in client’s hands regularly, and making sure that the clients really get the context of what’s being shown. Project meetings should show progress visually as often as possible. Additionally, completing functions at regular meeting intervals will keep confusion down and engagement up for both teams. The worst projects I’ve ever participated in are the waterfall method ones where communication is sparse and intermediate testing non-existent; the end product, no matter how good, will never fit the client’s needs like one with lots of communication along the way.
This agile communication method is true for deadlines as well. Setting small, intermediary deadlines with clients and then being held responsible for meeting them – together – keeps the project rolling. With regular discussions, the blocking needs are identified early on in the project so that they can be handled with minimal overall impact. Often a vendor is looking for a client decision, but the clients can’t make that decision on the spot. At regular meetings, these details can be intelligently slid around so as to minimize the impact, and together discover what parts of the project can keep moving even while one part may be blocked. An updated timeline should always be an outcome of a meeting – one that all participants have had the chance to buy into.
Despite doing all of the above well, sometimes things just aren’t working for one or both parties to a software development project. In my experience, this will become evident during regular meetings, or when meetings start getting canceled often. Project meetings as a barometer of project health are a crude measure, but they may just provide the window needed to save a project, or to negotiate a wind-down on the best terms possible.
What are your project management meeting outcomes? Share your experiences in the comments below, or with me at @trackmymind on Twitter. Happy projects, y’all!