Creating a Project Plan for Your Software Team

What stands between any brilliantly conceived startup and new development or expansion? Funding. So what does the savvy entrepreneur do? Sell — either by enlisting the help of business development professionals or by recruiting advocates to form a small salesforce.

The product advocates scatter to the four corners of the country, and they return having committed to a host of new functionality and capabilities to clients who promise to sign on and work with the energetic startup if ‘X’ number of features are developed. Say five product advocates each come back with a list of 20 proposed features guaranteed to hook the next “big fish.” Developing 100 disparate, and not to mention monumental features, in the time it takes to close with a client is nothing short of miraculous.

What happens instead is generally an avalanche of broken promises. Avoid it by empowering your product advocates or sales force with an accurate and equally inspiring development story. Write one by creating a project plan.

Creating a Project Plan

Forming Your Product Leadership Team

After defining the technical requirements and content needed for development, (see our post on feature prioritization) the next step for product managers, project managers, development managers, VPs of Product Development, CTOs or CIOs is working with your team to define your product roadmap. Gather a trusted set of managers and leaders to plan the creation of features identified and originally sorted in your prioritization matrix.

This collaborative group might include the business stakeholders, SMEs in other areas of the business (Operations, Customer Support and Sales) along with leaders in Design and Development. Having Design and Development represented at the table is especially important, they can level set realistic delivery expectations of their teams at the onset.

Determine a Common Vocabulary

Kick off the first meeting with your product leadership team by defining a common vocabulary. Your vocabulary should include varying states of commitment. Use the following three designations as a starting point.

Targeted: This represents an intent to deliver but not a firm commitment accompanied by a detailed delivery plan.

Planned: Staffing allocations and technical estimations have determined a concrete commitment can be made.

Customer commitment: This represents a concrete commitment made to a customer that cannot be moved.

Released: Development has been finalized and deployed.

These commitments should be marked on your product roadmap as they are determined.

Determine a Schedule and Deliverables

Once a common vocabulary is defined, start creating a project plan by grouping features from your prioritization matrix into logical releases. Your Design and Development leaders can inform how many features should be included in the release based on the size and ability of their teams.

The next step is determining when the release will occur. Often releases are date-driven, preceding a tradeshow or a sales meeting. Remember back to our entrepreneur? Building a roadmap to present to your product advocates takes the guesswork and personal decision making out of selling. It gives your product advocates clear guidelines as to what they can/should be selling — and when.

Organizing your feature sets should be driven by business objectives. For example, features might be grouped together in preparation to enter a new market.

At the end of the process grouping features and plotting releases, you should end up with a chronology that’s six to twelve months in length.

Close the meeting by asking Design and Development whether they see any issues. If Development expects one release to take time and a half after further thought, business stakeholders must assess the potential effects for the rest of the roadmap and adjust accordingly.

Break for Intensive Planning

These estimations needed to move intended commitments from Targeted to Planned should be completed in separate meetings where the Design and Develop leaders coordinate with their teams. During these meetings, more granular estimations should be completed. As is a common metaphor in development, this is where the true “sausage making” happens. It’s gritty work determining how new developments will integrate with valuable legacy systems or determining hour estimations. After staffing is determined and the planned release dates are either validated or invalidated, the Design and Development teams report back to the product leadership team about the viability of the plan.

Documenting and Visualizing Your Project Plan Process

1. Write Out the Rationale for Releases

After the development schedule has been finalized, ask the members of the product leadership team responsible for proposing each release to capture its relevancy and forecasted impact for the business. Keep these documents with the chronological graphic you create to visually represent the release schedule (more on that in the next step). Historical documents like this can be especially valuable in determining the success of product leadership and development teams over a longer course of time or as organizations restructure.

2. Create a Graphic Showcasing the Details of Each Release

Create a symbol to represent each phase determined in your project plan vocabulary. For example:

Targeted: *
Planned: o
Customer commitment: +
Released: x

To caption each release, include the date, name of the release and a numerical label. Also, include a description of the enhancements included. (For the sake of space, this is left out of the graphic below.)

Creating a chronological graphic visualizing your releases provides high-level detail about the schedule in a simplistic, yet holistic way. Providing details on the enhancement that will be delivered in each release captures the critical decisions made during the planning process.

Meet for Monthly Maintenance of the Roadmap

During the initial meeting, the product leadership should confirm a working rhythm and regular meeting schedule. Generally, meeting once a month is a good interval to use in reviewing the product roadmap. It allows enough work to be completed by the Design and Development teams that any roadblocks can be reported to the larger group.

Adding features to planned releases during these meetings should be done with extreme caution. Dependencies must be taken into consideration. For example, expanding a release that precedes a customer commitment, could invalidate the timetable and put the commitment in jeopardy.

3 Ways Creating a Project Plan Can Save Sanity

It Acknowledges There are Varying Levels of Commitment

The product roadmap level sets expectations between targeted and planned commitments allowing the Design and Development teams room to identify what they can realistically deliver.

It Keeps Score Visually

A year down the road if the deliverability of your development team is called into question, you have a visual scorecard to share agreed upon by members of your product team. The roadmap paints a picture of dependencies and the sequence of releases.

It Prevents Business Leaders from Getting Mired in the Execution of the Releases

By separating the planning meetings held by the Design and Development teams from the larger group meeting scheduling releases, it allows business leaders to target releases without getting stuck in the weeds managing staff allocations or deep technical discussions.

In Conclusion

The product roadmap is a tool, albeit a highly valuable one. Remember that. If a pressing business need arises, don’t be afraid to go back to the feature prioritization matrix and reorganize the features into an intermediary release to accomplish necessary objectives. Use the existing roadmap to understand the releases that must shift to accommodate the new need.