Good Development Project Planning: Establishing Project Champions

In the last WinDevPro UPDATE I touched upon some recent requirement gathering problems I encountered, and how that both bruised my ego, and had a negative impact on project delivery. As part of that WinDevPro UPDATE, I asked for feedback and mentioned that I'd do a follow-up if I received enough. Happily, a number of you emailed and commiserated, and also sent along some great advice. What follows is a synthesis of that feedback, along with a couple of my own thoughts on the subject since two weeks ago.

Related: Design By Committee and Other Bad Ways to Plan Development Projects

Commonly Mentioned Solutions or Approaches

A couple of you actually mentioned bosses who caused problems with the requirements gathering process. Sometimes bosses tried to include too many members in the design committee and sometimes they tried to get away with staffing the project with too few people - only to get cranky (or blame developers) when other departments or users pointed out flaws. In fact, in one anonymous email that touched upon the last point, a reader stated, "I think a designer or developer also needs to be prepared to be a psychologist as well. The dynamics that go into egos and conflict mgt., etc. mean that you'd better be prepared to effectively deal with different and/or difficult people. You must overcome your own natural defensive instincts if you hope to move forward. I recommend that books on dealing with difficult people and this short article should be in your arsenal."

The short article my correspondent mentioned was posted on the Psychology Today website. It discusses strategies for dealing with difficult people. This may sound a bit goofy on the surface but actually makes sense. In fact, given the highly introverted natures of many of the folks in our line of work, learning how to deal with others on a more personal level could help make a big difference.

Related: Could Not Establish Trust Relationship with Remote Server

A couple of readers also mentioned taking a more iterative approach to determining requirements. Don't try to get everything done in a single, monolithic effort. Rather, manage a project by taking smaller baby-steps and modeling proofs-of-concept along the way for the business groups and end-users that have a vested interest in the project. Likewise, a couple of readers also mentioned that good use of defect and bug-tracking software could help make it much easier to get larger design committees to provide feedback and input on iterative pieces of the puzzle in a more asynchronous way. And while I think that iteratively processed and asynchronously commented-on projects would make a great deal of sense in terms of mitigating some of the problems I encountered in my last project, I tend to think that they're not complete solutions. In other words, they're great coping strategies that I wish I had considered. But they still don't address the problem of letting too few or too many people in on the design process. Happily though, while thinking about some of the feedback, an idea occurred to me.

A Lesson Learned Locally

A great IT Hardware and Services company that I occasionally work with, Coeur d'Com, (when they need SQL Server administration or development help) frequently uses an approach that has contributed to success on consulting or implementation projects. Coeur d’Com makes sure that each project it takes on with a client has a contract stipulating that the client needs to provide a project sponsor who basically takes full responsibility for the project outcome. This sponsor could be the CEO, a business manager, or a member of the IT staff—it doesn't matter who the sponsor is. What does matter though, is that this sponsor is responsible for making all decisions for the project rollout, signing all approvals, approving any and all changes that need to be addressed during implementation, and either handling project management or assigning that task to someone else who will communicate with everyone involved.

Taking this approach obviously doesn't magically cure the kinds of integration problems that typically come up during complex hardware and infrastructure integration projects. But it does allow Coeur d'Com to focus on the solutions rather than forcing them to track down who has keys to the server room or who can approve a simple change. Instead, the sponsor ends up being responsible for these tasks - and since the sponsor is already an insider, he or she is typically well suited to being able to handle these kinds of problems. This in turn, lets Coeur d'Com focus on technology, implementation, and best practices rather than getting bogged down with minutiae.

If developers (or anyone in IT for that matter) took a similar approach on a regular basis, they might be able to avoid many of the problems that I encountered. In fact, had I taken the approach of defining a champion (or sponsor) in my latest development project I would have known much earlier about some of the strategic problems with my planned feature set and delivery. Or (more importantly), assuming that I didn't get that feedback early on, any departure from what I was attempting to do and what was really, truly, needed (as defined by upper management) simply wouldn't have been my fault. Although this is still not an ideal solution, it is one that would have let me focus more attention on development and integration rather than on project management. If the onus for getting the requirements and specifications correct were on someone within the company, it would have made my last project considerably much less painful because that person would have likely gotten applicable buy-off from anyone with a vested interest in the project's direction.

Champions: Sponsors at the Department Level

Now, while I think that the term champion is a bit much, I can't help but think of how applying the notion of sponsors to most development projects would fare. In the case of freelance development projects, the notion of assigning a sponsor seems to be a no-brainer (and I really wish I would have thought of this prior to my last project). But what about in larger organizations where development is done in-house? As nice as it would be to throw responsibility for the project over the fence to a sponsor, that's likely not going to go off very well, which means development teams are going to have to be responsible for gathering input and requirements.

But as I pointed out in my last WinDevPro UPDATE, figuring out whom to include is a double-edged sword. On the one hand, if you don’t involve enough shareholders either you fail to account for something huge or you risk creating a solution that is limited in scope, ends up being hard to integrate system-wide, and only provides tactical instead of strategic benefit. On the other hand, if you include too many share-holders your project will never get off the ground. At the bigger companies where I've worked as an in-house developer (as well as in cases where I've consulted), I've observed that inclusion in the requirements gathering process is a bizarre ritual where swarms of people from multiple departments end up getting involved (almost as if failure to be included is some sort of death blow to the egos of the uninvited).

As such, it seems to me that being brave enough to limit participation through the establishment of champions from each department would make a lot of sense. In this way, champions would be responsible for communicating all needs to and from their departments. And in cases where a few departments only had marginal interest, appointing a single champion for a couple of departments would seem to make a good deal of sense too. Ownership of concerns would continue to exist, but wouldn't all be placed on developers, managers, or their assigned project managers.

But what are your thoughts? Feel free to voice them in the forums or contact me directly if you'd like -because I'd love to hear what your thoughts are.