Modernization: Building a modernization project team

What is the goal of the project?

Before getting into team structure, you’ll need to answer three questions:

1. What is the desired outcome?

2. Who is The Client?

3. Who will be The Sponsor?

1. What is the desired outcome?

Just as the business case is important for project approval, the value of the modernization project (ie: why applications need to move to the proposed future state) needs to be communicated in a public way throughout project execution.

I once joined a team doing a fact-finding mission about container technology. We had done a number of meetings and were working on a proof of concept. But something was not sitting right in terms of our direction. So, at the start of a session, I opened a presentation with a single slide that asked “What do we want to achieve? Why do we want to achieve it?”

The room got very awkward and quiet. The executive who was driving the project had been sitting at the end of the table listening in. They suddenly got up and left. In the very awkward silence that followed, someone finally spoke up and said, “We don’t know.” I'm sure there was some high-level objective driving this work, but not communicating this with the team was a mistake. We needed that information to focus our efforts.

The definition of what needs to be done and why it's being done should be published in a place that all team members can access. When there is confusion or misalignment, this will act as the ‘north star’ to guide the team.

2. Who is The Client?

After a business case has been approved, generally the business unit that owns the application(s) becomes The Client. The most valuable role for The Client during the modernization project is to validate that the right thing is being built. Specific people within the business unit need to be selected to provide this feedback, and they need to be able to speak to concerns of the business unit’s leadership.

Even if it's a cost-saving modernization (such as upgrading or replacing middleware), there needs to be validation that the changes don’t affect the functionality the application currently provides.

However, sometimes feedback can feel a bit like playing a game of telephone, specifically if the application is used by clients external to the enterprise. The product team selected to do the work might not have direct access to these external clients. There could be many reasons for this, most of which stem from enterprise silos and the squads that form around them. This is an unfortunate situation that is sometimes unavoidable. This brings us to the next important role that underpins a solid product team.

3. Who will be The Sponsor?

If the project becomes blocked or the team is unable to get access to what they need to be successful, a Sponsor needs to be called upon to assist.

It’s tempting to select the person who made the business case for this role. But, as discussed, legacy enterprises can be interesting places. The person that did the business case might have just been the resource available at the time. You need specific things from The Sponsor for a project like this to work:

1. They should care about the value provided by the modernization

2. They must understand how the efforts of the product team connect to this value

3. They should be able to affect change in the enterprise (ideally across silos)

This person will most likely be at the executive level or one degree of separation from that level (and they have the ear of influential executives). This is a critical role should the team meet some of the challenges systemic to enterprise environments.

Team structure

For execution that produces value to occur, the team must be able to easily achieve agreements while balancing the right amount of requisite enterprise knowledge and innovation.

An example of an enterprise team that achieved great things was the Lockheed Martin team that built the SR-71 Blackbird in 1966 (codename Skunk Works). 

The lead of this team, Clarence “Kelly” Johnson, wrote a list of rules around how a project should be organized and operated. Once you get past Johnson’s outdated use of pronouns and some of the nuance around the industrial military complex, you will see that some of the rules he made for a team to execute in a highly political environment still stand up to scrutiny.

There needs to be one boss

Johnson said there should be one project manager (who I will call a Project Lead) who should have complete control of the project. Now as we discussed, there are a lot of factors in an enterprise that an individual might not be able to control. This is where The Sponsor comes in.

The Project Lead should be:

• Technical

• Emotionally mature enough to have difficult conversations in a professional way

• Have production experience in the enterprise

• Have a direct line of communication to The Sponsor and, if possible, The Client

With these skills and competences, this person should do the following:

• Work on, or even own, the architecture of the application

• Provide descriptions of work and the success criteria for its completion

• Review pull requests on the code base, providing feedback

• Meet with clients to collect feedback on the app

• Escalate issues to The Sponsor

In terms of discussing the scope of the project or any potential issues in the delivery, the Project Lead should be the one interacting with The Sponsor and The Client. This might fly in the face of many enterprises that wish to have an open culture, but remember that we are trying to execute in a tight time frame. The openness should exist for the team to bring up concern to the Project Lead, and for the Project Lead to report back to the team on what was done about their concerns. Let’s talk more about team size.

Keep the team small

Johnson talks about building “good” small teams. The number of people on the team is critical. Even if it is a big task, the team should be small. This is echoed in the two-pizza-team rule at Amazon. 

Fewer people means fewer chances for communication issues, including the risk of overcommunication. Excessive meetings are the death of productivity. But in many enterprises, software cycles are held hostage by endless meetings and sync-ups that never result in a consensus on anything.

Avoid unnecessary changes to the team

Johnson said, “The number of people having any connection with the project must be restricted in an almost vicious manner.”

There is an idea in some enterprises that team members should be rotated in and out to promote knowledge sharing. Although there is value in this, it must be done very carefully with a keen eye on project deliverables.

It takes some time for a good small team to gel and find its groove. Adding new people is a reset and potentially a disaster if the wrong personality is added to the mix.

Once a team has been selected, they should be given time to learn to work together. Once this is achieved, they need to be left alone to deliver. Switching team members should only be done once functionality has been delivered, and with the sign-off of the Project Lead and The Sponsor.

The following diagram depicts the key roles described to date.

The Project Lead and The Sponsor still need to build a productive team to get the outcomes valued by The Client.

Good people to have on an enterprise software team

The ideal team should be value-focused, with the right blend of enterprise experience and industriousness. The requirement for enterprise experience brings us to the next role the team needs.

The Wise Sage

The Project Lead should recruit someone onto the team who has been around the enterprise a long time and who has deep knowledge of how to get code into production in that enterprise environment. Likely candidates should have some of the following competences:

• They have put multiple applications into production in that enterprise

• They are open to discussing ideas

• They have a good relationship with the Project Lead

• They have good relationships with critical silos (the database team, infrastructure team, networking team, etc.)

People pitfalls to avoid

Let’s look at some personality types you might want to avoid.

Science experiments can cost you time

Some developers just don’t want to be in the enterprise. Perhaps they would rather work for a public cloud provider like Google, Amazon or Microsoft. For these people, adding certain buzzwords to their resume is what they want to get out of the enterprise.

Other developers just like to code with new software, but are not interested in the grind of getting to production or working with something that is more legacy. In short, they just want to play. These types of developers tend to push for “Science Projects.” Basically, these are opportunities for team members to play with whatever tech they are interested in and not be hindered by grinding to provide the promised value.

It’s true that new tech can sometimes be a game changer in a project. But, as I will discuss in detail in a later article, the right choices for an application in an enterprise environment might not always be the right choices from a pure engineering point of view. Exploring new ideas should be something initiated by the Project Lead with input from the Wise Sage.

Political players aren’t always execution-minded

Sometimes your team is assigned political people who, while they may be able to navigate silos, are mainly concerned with climbing the ladder. They may not care about the end user or even if the application ever gets to production. Someone like this might try to push the project in a different direction for their own gain — to put them into a room with the right people to move up the ladder.

Because enterprises usually have an excess of middle management, sometimes someone senior will throw people like this into a project, and there is no way to push back. In this case, the Project Lead needs to be empowered to escalate to The Sponsor if someone is derailing outcomes for political gains.

Setting expectations with management

Thus far, we have established the following basis for building an ideal modernization team:

• Agreed value the modernization will provide

• A Client who will provide feedback

• A Sponsor who can unblock the project and understand the importance of its value

• A Project Lead with deep technical skills and experience in the enterprise

• A Wise Sage with tons of experience and relationships in the enterprise

• Developers who are ready to close the stories assigned to them and can take feedback from the Project Lead

In my next article, I’ll discuss how to decide on your strategy for modernization.