Project Transitions - How to Strike a Win-Win Deal?
I have always wanted to pen down my thoughts on how to make a project transition a win-win deal for both the parties, i.e. the project team as well as the individual leaving a project. This article captures certain challanges and possible solutions to over come them.
- Overcoming the inertia and accepting the changes more realistically:
This is probably the first thing everyone in the team, right from the developer to the manager, should come to terms with. They ought to appreciate and then accept the fact that development phase of the project phase is over, and the project has now entered a new phase, the maintenance phase. It is very important to understand that a development project and a maintenance project are not the same. Maintenance projects are a different ball game altogether. Hence it calls for a change in approach to day to day tasks from everyone in the team
How can the team ensure the time lag involved in adjusting to the new phase of the project is minimized?
A formal kick off meeting that involves all the stake holders to define the roles and responsibilities of each team member clearly, at the earliest, definitely helps. Bringing in awareness in each team member about various aspects of the project like the new reporting structure (changes if any), SLA, roles, escalation process, etc. Handle project exits gracefully The transition phase of a project is also the phase of the project where people move in and out of projects.
- Why can’t project exists be handled gracefully?
How can frictions involved in handling project exits be handled with grace?
Why does a friction arise in the first place? One reason that comes to my mind quite immediately is expectation mismatch. I sincerely feel that if there are enough avenues and channels created in the project, for every team member to reach out to their manager for discussing their short term and long term career plans, we can definitely minimize the friction involved in project exits and have smoother transitions. Project transitions can also be looked at as an opportunity in disguise. What kind of an opportunity am I talking about here? A project transition offers a great opportunity for the organization in general and a project in specific, to show great levels of maturity in terms of their approach to handle the talent pool, respecting the career aspirations of its people and show highest levels of professionalism in handling project transitions. Think about it. Who says only developments projects are challenging? It’s quite a common notion that a development project is usually more hectic and challenging when compared to a maintenance project. While I agree with the hectic part of it, I feel a maintenance project can be equally challenging and sometimes even more.
The most challenging aspect of a maintenance project (I am specifically referring to the one where the maintenance team has access to the code base) is the ability of its team members to dig through other people’s code, understand the system end to end, and also enhance it. All this expected, with a caveat that it must not break the existing system.
I sincerely feel that efforts should be made to equip team members with more than just good coding skills to work effectively in a maintenance project. This may call for providing programs that would benefit the team members to understand the project life cycles better and cope with them effectively.
A maintenance project puts to test, one’s ability to do impact analysis before carrying out enhancements. It also demands quick learning abilities since not all project have the luxury of time to ramp up for support. Hence team members should be able to ramp up really quick.
You would also agree that very rarely would a project have the luxury of retaining the entire development team in the maintenance phase too. Hence ensuring that all arrangements are made to equip new joinees with the necessary knowledge transfer is quintessential. This is also one area where we can explore for innovative techniques to achieve it.
- Drawing a road map for every team member is as important as drawing one for the project
As most of you would agree, project interviews are one of the widely used techniques for recruiting new team members for a project. A project interview is often carried out against a requirement, and for a designated role.
As the time progresses and project grows in size, how can the project ensure that it can cater to the changing needs of its team members and to an extent the project itself? What can be done to make sure people are clearly informed of where their career is heading towards?
As the project grows or starts to hint any growth, it is very important for the team to assess the availability of new opportunities within the scope of the project and communicate the same to the team members. By doing so on a periodic basis, each team member gets a chance to make informed decisions when it comes to continuing with a project or to move on to a newer one. It works in the favor of both the project as well as the team member(s) in question.
Most of the times when the organization wins a client and spends considerable time in knowing the customer and their business, they utilize the opportunity to draw a road map for the client so that it helps the client know how the organization can help them grow.
I am always amazed why the same cannot be applied to a project. Look at this way. If a project has team members and they have spent considerable time in the project, why shouldn’t a project to draw a road map for such team members? I am sure it would help the team members, the project as well as the client since everyone is aware of the kind of roles or responsibilities them team members would taking up, going ahead.The project can also carve out a suitable space for them. You may ask. What about a team member who is recruited for a short term requirement? How can a project chalk a road map for such team members? I think it can be addressed in the following ways: I understand that it is practically impossible for projects to draw a career road map for such a team member within the space of the project. But it would not be a bad idea to discuss and understand their career aspirations since any such matching opportunity found in future can always be offered to the team member.
Another way to address this issue is to avoid short term recruits (I know I am deviating from reality here) for any project, purely in the interest of both the project and the team members. A project team must plan such recruits only if gets really inevitable.
P.S. In the end I feel this phase provides a great learning opportunity to everyone associated with the transition phase. It’s just that we must be open to learning from such experiences and works towards smoother project transitions.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)