The Dark Side of the Moon feeling

This morning I had a moment to reflect on how differently I’m able to interact with my two sons, one 15 and the other 13. My oldest son has reached a point in his life where he enjoys conversation. No subject is out of bounds and I think I get as much or more out of the discussions as he does. This is in stark contrast to what my younger son is able to provide at the moment. With him it’s the typical parent-child dialog where the parent has to play 20 questions just to get anything out of the child and there are more moments of silence than moments of verbal exchange. I’m not complaining, I realize this is typical and I had the same experience with my older son when he was that age. I’ve come to consider that age as a “Dark Side of the Moon” period. But it is very frustrating.

I can only imagine how anxious the engineers at the Kennedy Space Center were when the Apollo capsules broke communication as they went around the moon. It occurs to me that there are many examples of this in everything we do, including software development projects, and it underscores the value of frequent and clear communication.

Avoiding long lapses of communication is a good thing in all facets of interaction. One of the drivers of putting your compliance processes online is a strong need to broaden and improve communication with the researchers by providing a site that allows them to get status whenever they wish. This need isn’t limited to the implementation of the solution but continues on in the operation of your site and never really ends.

I think back on the various software development methodologies that have had their time in the spotlight over the years and can truly appreciate how uncomfortable some of them can make the “business owners.” In the Waterfall approach there are long periods of silence as the development team dives deep into design or implementation. In these deep dives, there are few moments to report any demonstrable progress. Though I have my own biases, I’m also willing to concede that all approaches have their strengths and weaknesses. I do favor, however, those methodologies that increase the number of demonstrable touch points but this requires commitment and participation by all involved in the project. It also requires a different way of structuring development.
Over the years, our Professional Services team has honed a development process that is uniquely tuned to our own development and configuration tools and it’s been pretty effective. This doesn’t mean we’ve stopped looking for ways to make it even better, however, and we’re always making incremental improvements. Communication plays a critical role in the process and I feel that as we continue to push ourselves to improve, we have the opportunity to reinforce communication in the form of status updates that includes having something new to show at each stage of the way. So far, I’ve avoided placing labels on how we approach design and implementation. I’m certainly no purist and I don’t believe that any single methodology can be applied literally. I do like many of the elements of an Agile methodology, however, especially the concepts that deal with more frequent, demonstrable milestones in the form of development iterations. By showing rather than telling, real feedback is easier to collect and there are significantly more checkpoints throughout the project to make minor course corrections in the approach. In this way, we avoid those trips behind the moon.
So how does this desire for fewer gaps in “communication” influence the approach we take to design, implement, and deploy a Click-based solution? How is the total project broken down into many demonstrable milestones? I’ve been thinking about this quite a bit lately as I weigh the successes of past deployments using our current methodology against the promise of achieving results that exceed the original vision by facilitating frequent, demonstrable checkpoints along the way in order to overcome the all too frequent times when the original vision and design seem less than ideal when finally implemented. One thought is to implement in “chronological order”. By this I mean we can follow the data with our implementation, starting with the population of data into a new project, following that data through submission, review, disposition, and then tackle the follow-up processes. In may respects we’re doing this in our development approach today, with the difference being that we put all of the design investment for the entire project up front. I wonder how it would feel if we break up the design into multiple phases interspersed with development.
There are many reasons for this approach to fail, most of them unrelated to the actual technical implementation itself. Literal adherence to long established procedures established by the Project Management Office can be a barrier to change and overcoming long held beliefs by the individuals involved in the extended implementation team can also make implementing a new approach more challenging. And then there is the ever present need to arrive at an educated guess at the total effort and cost of the project before it even begins. Also, equally important, is the willingness of the participating business representatives to acknowledge that the early demonstrations are not of finished project but instead represent the solution as it is taking shape and that they provide opportunities for minor course corrections throughout the project. For such an approach to succeed, it requires the buy-in from all involved from the very beginning, but if that can be achieved, I believe the ultimate results will be much closer to the vision than the early designs promised.
Real demonstrable checkpoints, delivered early and often is an excellent way to avoid that “dark side of the moon” feeling.
I’d love to hear your thoughts on this as the more we can share our ideas, the more we can all reap the rewards of success.
Cheers!