Andy Jordan is President of Roffensian Consulting S.A., a Roatan, Honduras-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at [email protected]. Andy's new book Risk Management for Project Driven Organizations is now available.
Caregiving is adaptive project management in its rawest form. Uncertainty is not the exception; it is the baseline. This practitioner shares how caregiving helped strengthen her PM skills.
How much do you challenge the directive? If project managers are always going to go along with what they are asked or told to do, then there really isn’t a lot of point in them being there.
“Done” is one of the most powerful words in agile. It brings closure. It marks progress. It gives us the satisfaction of checking a box and moving on. But what happens when “done” becomes hollow, and the value is nowhere in sight?
Commentary on Application Lifecycle Management spends a lot of time focused on the efficient development of software programs--the translation of business requirements into a completed application in a timely manner and for a reasonable cost. It also then goes on to consider the way that a particular release falls into the overall lifecycle of the product, considering that a software application is born, grows, matures and is ultimately retired and that each version is a step along that path. Where I don’t see so much commentary on ALM is the way that it can help you focus more on the applications purpose and less time on supporting the application itself.
As an ongoing metaphor throughout this article, I want to use the “compare and contrast” method with the application and the human body (yeah, it’s weird, but hang in there). To me, my body (including its constituent parts like the brain) is a means to an end. When it’s functioning correctly, it allows me to achieve my true purpose in life--being able to earn a living, spending quality time with the people I care about and of course entertaining my adoring fans on gantthead (!). In order to do keep my body functioning as it should, I need to ensure that it is maintained properly--fed, watered, given enough sleep, kept healthy, etc. Effectively, I implement ALM on myself--managing myself for the whole lifecycle. Maybe this isn’t such a crazy analogy…let’s explore.
Building the requirements and implementing the solution When I was in high school, I remember doing a computer test that asked me a lot of questions about what kind of activities I preferred, and based on that it came up with a recommendation for what I should do as a career. For someone who wanted to join the armed services it was a real shock--it spat out the career of choice as being an author (oh, the irony). So I did the obvious thing after school--I went into banking. It took more than five years for me to find project management (by accident) and discover something that I truly enjoyed. I then studied to get my formal project management training, education and qualifications and built up my experience to become a better PM.
Compare this with the building of version 1.0 of our application. If we don’t do the right kind of analysis then we don’t accurately identify the business need--in my example, the software tool led me down the wrong path and caused more confusion for me than it resolved. If our research isn’t conducted in the right way then we don’t get the right data and we build applications that meet a need that doesn’t exist. It may only be a number of releases later when we find out the true need, and by that time our competitors are ahead of us--like me when I hit 25 without really knowing what I wanted to do when I grew up.
If you correctly identify the need and then take the right steps to address that need--building the right features into the software, implementing then in an intuitive way and delivering leading edge performance--then the rewards are evident. The same was true when I found project management and learned how to do it effectively.
Maintaining the advantage In our human body analogy, this is where we move away from the software lifecycle. In our personal lives we spend a lot of time and effort maintaining what we have built for ourselves. Professionally we read about our industry and profession, we maintain our certifications, we take part in professional communities, etc. In our personal lives we surround ourselves with things that improve the quality of our life--friends, family, a home, a car, hobbies, etc. And of course we maintain the physical body with nourishment and exercise.
Why do we do all of this? Because it improves the quality of the life that we enjoy, and it also increases the likelihood that we will be able to enjoy that life for more years than if we just allow ourselves to stagnate.
Yet more often than not, in software development we consider our job done when the product is released--it’s handed off to someone else to support, and we forget about it. That’s where ALM can help you, and that’s where we start looking at our product from its full life standpoint.
Maintenance of the human body has to happen every day; in software we can take somewhat longer timeframes, but the concept remains the same. Annual or twice yearly releases shouldn’t simply be an excuse to throw more functionality in. Instead, they should be a combination of a conscious step forward for the overall application and an opportunity to address any shortcomings that exist in the current version. That needs input from the ALM support mechanisms--in the same way as our body needs input, the advice of friends and family about whether we should apply for that job, the suggestions of the doctor (or the mirror) that we should lose a few pounds, etc.
This is where I think ALM can really add true value to the application. You need a support and help desk infrastructure that isn’t simply aimed at fixing problems, but is capable of identifying and analyzing trends to identify potential weaknesses. Processes that allow for the identification of the root cause behind those weaknesses so that we treat the underlying problem rather than just the symptoms.
Similarly, we need processes that allow us to keep informed about what’s going on in the industry, how the competitor’s new product will impact us, what the latest regulatory change means for us and what a takeover of a major supplier might mean. We need to be talking to our customers and find out what’s important to them--what they are looking for from our application (preferably before they realize that they need it) and what features are becoming redundant.
Of course none of this is any good unless you can do something about it--back to the need to identify the true need and address it properly. You need the people and processes to help you distinguish the must-haves from the nice-to-haves, the real pain points from the annoyances.
Finally, you need to be able to cost the solutions out and make the right decisions about how to spend the limited budget in the most effective way (in my analogy I think that my life needs a Porsche, my wife feels that it needs a new kitchen).
Getting these decisions wrong isn’t usually fatal to ourselves or our application, but it can have a detrimental impact--it can set us back, lead to disappointment in our personal lives and a loss of competitive advantage with our application.
So what the heck does this all mean? My human comparison is a little controversial--the idea is to try and make you remember the article and the underlying messages, but there is validity to the analogy. In our personal lives we take the time and effort to look after ourselves and those we care about. In our professional lives the same approaches can achieve the same results. They need more formal processes, and they may need some software tools to support them, but fundamentally application lifecycle management is just that--managing the end-to-end life of the software application--and all aspects of that life. That really isn’t so different to what we do almost without thinking when we take care of ourselves.
The challenge with software can be getting people to care. We can all think of situations where we have said, “What were they thinking-? I bet they don’t do that at home.” It’s true--people don’t always have the same level of concern for their professional responsibilities as for their personal ones, and the best set of processes in the world are no good if you have general apathy toward them. Also consider that people don’t have a life-long connection with the software that they build or maintain. If I neglect my body, then I have to live with the consequences; I can’t simply go and find another one. However, if people become fed up with their work responsibilities, they can go and find another job. The consequences aren’t the same.
If you think that my analogy is crazy, that’s okay (my wife did when she read it, and I think I’m going to pay for the kitchen comment), but at least consider the message--a holistic approach to managing the “life” of your application can pay dividends for you.
Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at [email protected]. Additionally, Andy is Vice President of a new Canadian professional project management body--the Project Management Association of Canada. Learn more about them at www.pmac-ampc.ca.
