How to deal as PM for a technical-only refactoring project

Question

Our company has accepted to do a full-scale refactoring of our core IT product and I'm supposed to act as PM for this project. First some background info: The project is 5-6 years old, build as a monolith of code by a single guy (for about 3 years) and then developed further by a small team (without the first guy). Right now the company and team further extended so it became problematic to accommodate a large team being productive by working on such an outdated (architecturally speaking) project.

The idea of such refactoring came from one of the senior developers (from the ones that took over from the creator of the project) in form of various technical documents about how the project should be modularized, structured in correct layers, adapted to modern models and frameworks, etc. So this guy (let's call him Mike), ended up as an teamleder/architect of this project to which management committed some important resources.

One of the problems is that this guy is a difficult/conflictual person to work with so I was also bought in as (non-technical) PM to handle this project.

My main problem here is that the project is purely technical (e.g. if everything that Mike suggested will be done, business wise the product would have the same functionalities/look the same) so it will be very problematic for me check the deliverables of such project. Mike's difficult personality will make this even more cumbersome as he can't really find (by himself) the way to explain the business scope of the various "tasks" that he suggested.

There are a couple of other seniors (that will be part of this team) that I would trust more with translating technical plans into business understandable projects, but they are not the ones who came with this project so this is a bit of "Mike's project".

Of course having a good relationship with Mike is one of my main goals (and one of the reasons I ended up in this position is because I was the only PM to accept/be able to work with him in the past:) ), but I can not let him solely lead the project and trust him. Especially since it seems the project can not really be delivered in steps, which make it even more complex to follow it.

Answer 1

Looks like it is a rewriting project not a refactoring project

How do I know this? You said, "the project can not really be delivered in steps". Refactoring can (and should) be done a little at a time, say for example, in each sprint as part of feature development and bug fixes.

Stack Exchange cofounder Joel Spolsky calls rewriting "the single worst strategic mistake that any software company can make".

Others have said similar things. For example, Why You Should (Almost) Never Rewrite Your Software.

However, now that you have the PM role on this project here is what I suggest:

1. The first thing you must do is to articulate the business drivers of this project - maintainability, large team productivity and whatever else - and get buy-in from the stakeholders. List the changes that are planned and tie them back to the business drivers. This will help you to manage the scope of the project, to some extent. Otherwise whatever catches Mike's fancy is what will get done.

2. Press to deploy code to end-users at the end of each two-week sprint. If this is not at all possible, at a minimum, ask to deploy three or four times as the project progresses. This will help to minimize project risk.

Answer 2

There are really two questions to answer here: the technical aspect and the project management aspect. I'll focus on what appears to be your concern: managing a difficult team member who has perceived authority and (possibly) detail you don't have. I do think this can be managed with skill by drawing on the other technical expertise in your company.

Relationship building is important but so is facilitating open exchange. When people CAN act as gate keepers due to their key role on a project they DO tend to function that way to assert their influence or power. So the heart of this problem seems political.

I would suggest framing your solution to these issues as part of the project plan and your own management processes; a few suggestions that I've used with a somewhat similar scenario:

1) "The Bus Rule" -My concern was that at any given time a project member with important knowledge in their specific role was the only person with that information. Thus, everyone was required to participate in knowledge-sharing that looked something like a rotating "knowledge download." For project stability I feel that each person should have someone who could step in should something catastrophic happen -- as in getting hit by a bus. This also helps take the keys from the gatekeepers.

2) "Red Team Tactical Response" A red team is an independent group that challenges an organization to improve its effectiveness. The United States intelligence community (military and civilian) has red teams that explore alternative futures and write articles as if they were despotic world leaders. Little formal doctrine or publications about Red Teaming in the military exists.[1] Private business, especially those heavily invested as government contractors/defense contractors such as IBM and SAIC, and U.S. government agencies such as the CIA, have long used Red Teams. Red teaming refers to the work performed to provide an adversarial perspective, especially when this perspective includes plausible tactics, techniques, and procedures (TTP) as well as realistic policy and demands. The key here is to make "criticism" a regular part of the group process. The red team role is often random and rotated (I would include Mike as a part of this as well).

These are perfectly normal practices for risk mitigation that take the focus away from a possible negative individual personnel matter to a "business as usual" that helps make everyone more comfortable with ownership and speaking up. By increasing interdependence and engaging the technical expertise you may not be comfortable with, you've built in content-specific oversight into the overall project management.

By making this about collective-task management and project responsibility it removes the possible "me against him" issue. Remember: this is not "mike's project" the project implementation and ownership rests with you. Let Mike know you need his support in ensuring the success of the project.

Answer 3

I think you primary issue on which you should be focusing is your problem employee. A hard_to_work_with person decays teaming and sustainable, predictable overall performance despite whether or not this person produces good work product. No organization, except for maybe those focused on extreme cutting-edge, innovative research (and I am not even so sure here), should put up with this. If it were a problematic cog on a machine, you'd turn the machine off, unbolt the cog, grab another, replace, and turn the machine back on.

The concept here is no one is irreplaceable. We are all cogs that can and should be removed when we are no longer fit for service. Not a popular concept, I know, but businesses are not here for us; we are there for them, to produce whatever it is we produce to achieve whatever mission. The great work product of a problem employee NEVER outweighs the degradation of overall organization capability that a problem employee causes. It seems to because you can easily see it and you assume the organization can 'work around' him/her. And what the organization is now producing by way of results becomes your new normal, so you don't even recognize the decay anymore.

Replace and finish your project.

Answer 4

Refactoring an existing product gives you some advantages in dealing with a "difficult" lead dev compared with developing new products or features. You have a clear, objective definition of done (product must externally behave exactly as before), so you'll largely be spared from clashes over which feature are important or different interpretations of requirements. 

It helps to have a comprehensive spec of the current behavior of the system. If you don't have this, I would argue that developing such a spec should be your first priority. This will represent your objective yardstick for progress and definition of done. It's also a task that won't depend on the lead dev to complete. 

Better yet would be a comprehensive automated test suite that continually verifies the proper functioning of this system. At the start, all the tests will be red. You're done when all the tests are green. Yes, it requires writing a lot of test code before touching that product code, and it can be harder for a non-technical PM to champion. But it will not only aid in the refactoring but will make future maintenance safer and faster. If Mike is truly focused on modernizing and properly structuring the codebase, he should be a fan of this. 

Also, I question the notion that the project can't be delivered in steps. It may not be able to be pressed into production in steps, but any project of size ought to be splitable into steps for the purpose of managing the workflow. Features that are dependent on multiple parts can have some parts faked/stubbed in so that you can check them off as complete. I would push hard for this, and enlist the aid of other stakeholders (like Mike's boss). Your bosses should be expecting incremental progress reports, so make it about you and Mike working together to keep them off your backs. 

Answer 5

If you cannot simply replace Mike then you will need to figure out a way to work alongside him. If you take the lead on the non-technical aspects of the project, and Mike is able to deliver on the development and team lead responsibilities then it will still be difficult but it can be a successful project.

The part missing from your question is the business benefit of doing the refactoring. Technical reasons are usually to improve the efficiency (so performance improvements) or the elegancy of the code that should make it easier to maintain in future. Both of these can save a business money in ongoing development, after the initial overhead of the refactoring effort.

The first step is identifying roles for the project and bringing in someone senior from the business to look at what the financial benefits to the business will be for the refactoring, and sponsor your project to support/strengthen any decisions you need to make that may be opposed by Mike.

If it makes commercial sense to refactor then Mike can be made responsible for the technical implementation, but you take control of scheduling and resource prioritisation* and bring in technical QA resource (if you can) to get an effective dev > QA > sign-off delivery process going. The QA resource can then support you in pushing back any technical issues to Mike allowing you to concern yourself with scheduling and liaising with any business stakeholders through to project completion.

* It may help your relationship with Mike if you give him the lead on deciding which resource works on which task. One way of doing this is planning all the tasks with the team then putting then letting the team choose which ones they want or allowing Mike to allocate resource. BUT you must ultimately be able to make any final decisions on resource priorities over Mike if e.g. a resource is required on another project that is higher priority. You may need your project sponsor / senior management to support any such decisions.