Coordination with Others
It’s easy for a close-knit team to see themselves as the center of the universe, or the most important aspect of a project. They’ve been given, or have taken on, the responsibility for accomplishing some piece of work. In fact, dividing work into projects may reflect a concept of dividing some larger purpose into categories of similar types of work, each to be given to teams and individuals with the appropriate skill set. There are, of course, pros and cons to such a division. One of the consequences is that the different parts of the effort need to be coordinated and aligned to achieve the higher goals, the intended outcomes. That coordination and alignment requires some visibility into the progress and expected future progress of the various threads of work.
Parallel Development
Sometimes in the grand scheme of things, it takes more than one team to deliver all the software functionality you need to have the outcomes you seek. Small incremental improvements are safe, but often don’t create the big breakthroughs in impact. Rather than have one team serially do everything that’s required for a large idea, it’s often preferable to have multiple teams working in parallel toward a common goal.
There are a number of ways this can play out. Perhaps you need to change multiple subsystems of a large system in multiple ways. Some of these might be system enhancements and some brand new. You might have different teams working on different subsystems or they may be working on different functional slices. In order to have it all come together, you need to integrate the various systems. And, as with all integration efforts, you don’t want to risk leaving integration to the end, but instead integrate over time as the systems evolve. Not matter how you’ve worked to decouple the various pieces, you’ll need a lot of collaboration touch points along the way.
It’s best if these touch points are “just-in-time.” If I’ve finished my system and gone on to something else, it’s inconvenient if I need to come back later to make an adjustment when another system tries to integrate with the functionality I created and finds it wanting. It’s both inefficient and ineffective. A jump back to previous work rarely catches the depth of awareness that previously existed, and such rework may not be of the same quality as the original.
When will a dependency be ready for collaboration, and what valuable work can we fit into the time before then? This is one of the questions that estimation may help to answer.
Other Systems
Often a desired change in functionality affects more than one system. A change in one system may depend on changing a backend service to provide the data or functionality it needs. From the perspective of that backend service, there’s no point in making the change if there’s no code that’s using it.
You can, of course, serialize the development of the two systems. You can develop the backend service first, and then start working on the system that uses it. This, of course, lengthens the total time of development to the sum of the time of developing each piece, and the delay between the two. Surely you’d prefer to develop these in parallel.
You could start developing both systems at the same time, mocking the behavior of the other system during development. This is a good strategy, but it has some pitfalls. The mocked behavior may not match exactly, leading to the need for rework when the systems are integrated. If the development team of the system that needs rework has “finished” and gone on to other things, then they’ll either have to drop what they are doing to come back to this, or the integration will be delayed until the other work is done. This sort of dynamic happens more frequently than you’d think, even in the completely serialized case mentioned above.
You’d prefer to have both systems ready for integration at the same time, and this synchronization requires estimating when each system will hit that point. And if you’re trying to minimize integration risk, you’ll want to have several synchronization points. You’ll want some basic synchronization early, to ensure that the systems are basically compatible, and get progressive detail in the integration as the work proceeds. You probably won’t be able to perfectly synchronize all of these integration milestones, but it’s worth the effort to try to come close. Integration points are a major source of errors in combined systems. Juggling the needs of two flows of work to do rework on one is a major effectiveness drain, and also a common source of mistakes.
Deployment and Operations
In most situations, the development team is not handling all aspects of the developed system. Even in organizations practicing DevOps, there’s a limit to how much a team can do. In most organizations, there are specialized groups for many activities, and handoffs to others’ care.
In organizations that have not embraced a DevOps model, there may be a separate team that deploys to production. Sometimes this strategy is chosen for security reasons, to reduce the access to production servers. If the server hardware is shared among various applications, having a separate team can make sense for preventing accidental disruptions to applications unfamiliar to the deploying development team. There are cases where the application is not hosted on a central server, and perhaps there is no facility for pushing the application from a central location to many runtime environments. Rarely are the development programmers charged with traveling to dispersed machines for deployments. All of this needs to be scheduled and coordinated.
In a self-hosted DevOps model, shared resources such as storage subsystems might be managed by an infrastructure team rather than have every development team stirring the common pot for their own needs. In such a case, this team will need advance notice of needs so they can ensure sufficient storage capacity for the new application, without interfering with existing ones. Increasing the capacity may require the purchase and installation of new hardware, and that may take a while. This suggests that it’s prudent to estimate and communicate these needs far enough in advance that this won’t delay the deployment. A separate infrastructure team will also have responsibility for keeping the software running that keeps infrastructure up-to-date and patched for security issues. These duties need to be coordinated with new deployments.
System Users
One handoff that’s pretty universal is the one to the system user. It can be helpful for users to know when a system will be available so they can prepare to use it in their work. Think how it would feel to have your work suddenly interrupted with an announcement that you had to immediately switch to an unfamiliar way of working. They may have logistical issues regarding changes in their workflow that are enabled or required by the new functionality. Can you tell them what changes they can expect, and when they can expect them?
Trainers
Consider the need for training the users of your system. Before we put new IT software on the desktops throughout the organization, we may need to train people on the new system. There will be differences in the operation of the new system from whatever they’re doing today. If there’s a wide user base, this usually means a significant training effort, visiting the locations of the users and training them on the differences and benefits of the new system. That needs to be completed prior to releasing the system, but not so far in advance that they forget what they were taught.
Prior to that, someone needs to design that training. This needs to be late enough to provide the training team with accurate information about the system behavior. That’s a milestone that should be estimated, so they can know when they can begin. Is there enough time between then and release for designing and delivering the training? They’ll need to estimate that timespan.
It’s likely they’ll need pixel-perfect screenshots prior to delivering the training. How late in their training design can they wait for those? When can you provide them? These milestones need to be coordinated so that release and actual use of the system won’t be delayed.
Help Desk
When new software, or a new version of existing software, is deployed, it is likely that users will have questions or problems using it. They may call the help desk for assistance. “How do I do this thing I used to do this way?” “Where did my shortcut go?” I’ve talked with help desk personnel who found out about a new deployment when the calls started coming in. It’s so much easier for them to help the users if they know something about the software ahead of time. When do they need to be notified so they can prepare?
The Customer Who Requested the System
People who have requested new functionality, who may not be the direct users of it, did so because of the benefit it provides to their organization’s work. The purpose of this work is likely not about software at all. They would like to know when their request will be fulfilled, and what other changes will happen at the same time.
If the system won’t be available in time for some of their needs, the users or the people requesting it on the users’ behalf may have to figure out an alternative plan. That may require some preparation, so knowing this in advance is helpful. Can you keep them informed appropriately?
Marketing
If it’s software for sale to outside customers, then we want to start a marketing campaign early to build up the buzz. We want to pique peak interest at release date. Customers love to be first in line for a new exciting thing. If interest peaks late, we miss a market window. If it peaks early, it may cannibalize current sales. Customers quit buying the current offering to wait for the exciting new one. This has become known as the Osborne Effect after the bankruptcy of Osborne Computer Corporation who announced a new computer model, killing sales of the Osborne 1 and the cash flow needed to continue development. What’s the earliest point they can start pushing the new system? How sure are you?
Packaging
Some software-based products still get packaged into physical boxes. If we start this project today, when will we likely need to start production of the associated physical components that have their own lead times, such as boxes, brochures, and servers?
Others
Organizations, especially larger ones, are complex systems. The actions in one place ripple through and affect the situation in other places. Often those at the place of action are unaware of the effects on others, and vice versa. Left unchecked, these unintended effects of local actions can encourage responsive action that, itself, creates further ripples. Visibility, both across the organization and into the future, can help. Who needs to know what, and when? How can you be aware of those needs and how can you provide the needed infor in a timely fashion?
Each of these coordination points is a milestone that needs to be communicated to others. It’s generally OK if they change, as long as you can give enough advance notice. The point is that you need to keep people informed, giving them sufficient notice from the start, and when the picture changes.