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.
The delivery metrics across your large-scale transformation program look strong. The closure report is signed off. The steering committee congratulates the team. And then, quietly, the organization continues doing things the old way...
The fiber cut problem in India is not merely the pace of infrastructure growth—it is the absence of safeguards to ensure that what has already been built remains functional, protected and sustainable. These eight steps can improve utility coordination and prevent cuts.
I’m currently working with an organization where the technical lead has been working with the main product for almost 10 years--right from the start. It’s a fairly small development team and from a technical standpoint this is his product--he is incredibly proud of what has been achieved, he has a constantly updated technical vision for how the product needs to evolve technically and he is a tremendously valuable asset for the business owner in defining the overall product strategy.
This is a very different situation from one that I experienced a few years ago in a different organization where there were two very different sets of developers--those that were responsible for building the product, implementing the product vision and creating the overall architecture; and a second, less-experienced team that was responsible for maintenance releases and minor functional upgrades after launch.
So which is better? Should the resources stay with the product throughout the application lifecycle, or should there be “expert” teams for the different needs of each stage of the lifecycle?
The advantages of full lifecycle resourcing The advantages of having consistent resourcing through the product lifecycle are fairly obvious. We have resources who understand the product extremely well, they are building on their own code and they have an excellent understanding of the way that the solution has been architected. From a project management standpoint, we can have a lot of confidence in estimates that they provide as they are the experts in the area. And when it comes to task execution, they are more likely to accurately determine if they can complete the work on schedule.
Extending the project management aspects further, the costs of development are also likely to be less as there will be no need to ramp up on the way that the software has been written (there’s no need to review the development style of someone else’s work and no need to have to “learn on the job”). The team may well have a sense of ownership of the application, which results in a pride in the software and a desire to make it as good as it can be.
As a contrast, in the other model there is no continuity--the “build” team will be moving on to the next project as soon as the current one is done and the “maintenance” team has to deal with all of the bug fixes, performance enhancements and minor fixes without the opportunity to be involved in the initial creation of the code and without the chance to influence the architecture.
I have seen situations where the development team responsible for building the application was looking to move on to the next project and ended up cutting corners on the coding knowing that it would be someone else’s problem to solve after the fact--not exactly the kind of thing that results in a strong application.
The advantages of dedicated build and maintain teams If you have separate teams focused on the initial application build and the later maintenance, then you can create a career path for your development teams. The more junior or less experienced developers are given an opportunity to learn about the more complex applications through support of them and don’t end up thrown straight into complex coding with applications that they have little understanding of. This likely will involve discussions between the maintain team members and the original developers from the build team, but that’s a good thing--it can lead to more creative solutions and provides coaching and mentoring opportunities.
This also frees up your most experienced developers to work on the most complex development efforts and makes the most of the money that is invested in these senior resources. It’s a lot more cost effective to have the expensive resources solving the challenges of creating a new product than in having them fix bugs.
At the same time, all developers are given an opportunity to work across applications and therefore stay fresh. The sense “owning” an application may also result in boredom and stagnation. Inevitably that will result in lost productivity, and the development approach of having separate build-and-maintain teams that move across product lines may end up being more productive.
Finally, this model allows for rapid new development growth. Under a lifecycle model, the developers are new at the same time as the product; but in this model, the experienced developers are the ones who focus on the new products, reducing some of the risk that is inherent in completely new initiatives.
The real-world factors Clearly there are advantages to both models, so which one works best for you? Should you have application lifecycle developers or not? There is another set of considerations--the environment in which they operate. If you have a business owner/product manager with very strong opinions, then he or she may not want a model where the technical lead has been working on the product for extended periods (and believes that they have a good understanding of the business aspects of the product and their own set of ideas about how the product should evolve). On the other hand, if you have a business owner who sees themselves in a partnership with the technical lead, then you may find that the single owner may work extremely well.
The size of the development team--and by extension the rate of turnover--also needs to be considered. If you have an environment where there are a number of new developers coming through the ranks, then they need to learn and grow. Working in a maintenance environment may be the right way for them to gain experience more quickly in a “safe” environment. In a lifecycle resourcing model, there is still room for them to gain experience--but it may be more limited and the opportunities to advance within the development team for their product may be restricted.
You also need to consider the product environment--do you have products that establish themselves in the marketplace for long enough to support a lifecycle approach to resourcing, and are there enough enhancements to those products to keep the dedicated resources involved and interested? Conversely, are there a lot of new products being introduced that would make the creation of dedicated product teams difficult?
Perhaps most importantly, the types of resources that you have need to be considered. If you are building a new team then you can recruit for the personality traits that you want, but if you are dealing with an existing development team then you need to consider the types of people that you have. Will individuals be motivated by the opportunity to “own” a product from start to finish, or will they see that as a punishment because they aren’t being given the opportunity to work on the newest leading edge development?
Conclusion I don’t think that there is a right or wrong answer here--every situation is different. In the two very different situations that I referenced at the start of this article, I couldn’t see it working any other way. The two models are polar opposites, but they met the needs of the company. My current situation is with the lifecycle resourcing approach; it’s fair to say that it is a client that I enjoy working with more--it’s a great environment and the sense of ownership that the team creates is remarkable. Everyone is desperately keen to see the product succeed, and it’s the right situation for the model--and that’s what is important.
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.
