What Your Software Development Plan Isn’t Telling You

Software development plans are a non-negotiable item for large-scale projects.

Whether your company has decided to partner with an agency to build this product, or you are handling the entire effort in-house, a comprehensive, structured, and accurate plan is crucial for planning strategy and allocating resources.

With a proper software development plan, management can review the respective workloads and timelines of each person involved, be they developer or stakeholder, and have a suitable baseline against which to measure actual project progress.

But as useful as a thorough plan is, it only reflects a single perspective of the project--and an incomplete one, at that.

THE RISKS OF A LARGE-SCALE SOFTWARE DEVELOPMENT PLAN

Complacent managers who only rely on the software development plan to oversee a large project are at great risk of missing risky planning, workflow and staffing issues, such as:

Initial estimates are almost always wrong

Even the most thorough business and requirements analysis is a victim of timing. Initial estimates are useful for building out the first version of a software development plan. But if you want more accuracy, your Project Management Office will have to use a two-stage estimation process.

The reason you need to two (or more) estimation stages is that your initial analysis and the overall plan are being built at practically the same time, and as such user stories and modules are incorporated piecemeal.

Additional estimates, which are done after the initial plan has been built, will be able to view the project holistically, and better be able to detect and evaluate links between work modules--links that will complicate the plan and increase the amount of effort required.

There may also be business needs and third-party integration issues that don’t become apparent until after the project is underway. A re-assessment once those issues come to light is essential to keep the project expectations and planning realistic.

The larger the scope, the greater the margin of error

Software development plans should allow for a margin of error, but we’ve found that most organizations miscalculate the demand of software requirements on the shorter end (underestimating the time required) when they should be leaving more room for error instead.

The larger a software project is, the more potential failure points there are, the greater the complexity of the dependencies, and the more layers of communication you will have to push through to get anything done. All of this adds up to plans that are likely to miss any target deadlines you set--especially if you don’t use a multi-stage estimation process.

Rework impacts multiple modules at a larger scale

When an issue occurs in a software project, the rework can easily affect other modules. This is true for both small and large projects, but the impact on the latter has far greater repercussions and cost. Understanding this impact is crucial for proper risk management.

If there are multiple teams, each managing their own module, then this may slow things down even further. The team managing the module with the original issue now has to communicate with the other teams and coordinate multiple fixes. For example, if the team developing the business logic for a multi-tier application has to make changes, the teams responsible for the application or presentation layers have to wait until the rework has been completed.

Greater risk of silos

Any organized software project will be composed of three working disciplines: business analysis, development, and testing.

In smaller projects, these disciplines are each represented by a few core people (and maybe even some overlap). Larger projects need to use more people in each discipline to cover all the work.

But this arrangement carries a big risk of encouraging silos, where one group or discipline are so caught up in their own tasks that they no longer communicate or work well with the others. Work now becomes competitive, not collaborative, and resentment builds up as things bottleneck. For example, developers would see testers as nitpickers that slow down the project, while the testers see developers as sloppy and submit rushed work.

The end result? Longer delivery times, more rework and missed deadlines. There is also a big risk of deliverables that either doesn’t function as designed or miss the objective entirely.

So given all of the above points, does that mean a software development plan is useless? Should management just draw the plan in broad strokes or even forego the plan entirely?

Absolutely not.

MINIMIZE THE RISKS IN YOUR PLAN

Your organization’s software development plan can still work, provided you take the following steps to mitigate your risks:

Cross-functional work cells

One way to minimize the impact of silos is to create cross-functional work cells. A cell is a small team composed of representatives from each discipline. A cell can be assigned more than one module at a time, but they have the sole responsibility for whatever they are given.

The idea is that each cell would be assigned a working module or user story to see through to completion. Because every cell is composed of people from each discipline, they will be able to operate independently without any of the usual bottlenecks that a traditionally segregated team composition would encounter.

In theory, each feature being worked on will be properly conceptualized, developed and tested promptly thanks to the close cooperation of the members of each work cell. There is still some risk of silos, but the impact will be minimal provided you build the work modules properly.

Which brings us to the next point:

Build cohesive work modules

If you are going to be assigning work to an independent, cross-functional team, you need to ensure that you assign them a cohesive collection of tasks.

By that, I mean tasks that have strong relationships to each other--either by theme or functionality. You get the best results, for example, if you give one team responsibility for an entire “messaging” functionality rather than giving the text module to one team and the voice module to another. The former is much more likely to result in an intuitive user interface, and the latter would be a haphazard mishmash of features.

But remember that you are not building a collection of separate features; you’re developing a single cohesive product or solution. Proper configuration management demands some interaction required with other cross-functional teams. Make sure the software development plan takes that into account as the project progresses.

Social capital and knowledge coordination

Your project is a complex endeavor that requires multiple skills, specialties, and levels of expertise to pull off successfully. No single person has all the knowledge required, and a single software development plan will never be able to address all of the questions or situations that arise.

That’s where social capital comes in. Social capital is the collective knowledge of your entire team’s network and can be tapped at any point to assist its members.

Management can help the PMO leverage social capital by facilitating a collaborative and consultative project environment. Establish tools for easy communication between workgroups and project locations, such as Confluence or Sharepoint for managing documents, JIRA or Trello for managing tasks and Slack or Microsoft Teams for communicating between teams. Push for the development of a comprehensive and accessible internal knowledge base that employees can use to share or research information.

Don’t be a slave to the plan

This seems counter-intuitive. After all, why establish a plan if you’re not going to follow it?

But while your plan can serve as a good baseline for your original targets, you also need to make sure it reflects what is achievable by the team.

When your PMO requests to update the plan, ask them why. Perhaps they did a second analysis (as mentioned above) and need to update the original estimates. Or perhaps someone else on the executive team changed the requirements (scope creep) and it means a drastic shift in timelines. It could even mean that there was a staffing change, and your plan has to update based on the resources you currently have available.

No matter what the cause is, it's your responsibility to both your PMO and to the rest of the management team to use a software development plan that is ambitious yet realistic. If this means changing the plan when there is a significant change, then so be it.

In Summary

Large scale projects require a software development plan to collect project requirements, solidify the development plan and organize project teams. And while this is a valuable document, responsible managers should be aware of what the document is not telling them.

Staffing concerns, aggressive goals, and inefficient work practices will not be reflected in your project planning. If you want to ensure success, these lurking software development process issues will have to be investigated separately, either by yourself or someone in the PMO.

But if you can account for and attenuate these hidden risks, then your large-scale projects will turn into software products that are much more likely to perform as expected--and do so within the allotted time frame and budget. So the next time your co-executives ask you about the project in the boardroom, you can give them your most confident and optimistic response.