Strategies for Getting Approval for Software Development Projects

January 28, 2021

Are you losing ground to more agile competitors? Is it time to modernize legacy applications?
Or make the big migration to the cloud?

Whatever you have in mind, you’ll need to start with a detailed software development project proposal; otherwise, your idea isn’t likely to go very far.

Below, we’ve shared a general project proposal format for software development initiatives. We’ll cover all bases, from identifying a problem and creating a technical proposal to communicating value to stakeholders and building a project approval workflow that gets the results as promised.
[adinserter name=”Software-Development-eBook-Offer”]

1. Understand the Problem You’re Trying to Solve by Performing a Technical Analysis

Before you do anything else, you need to understand what you’re trying to do. In other words, why do you want to build this product in the first place? And more importantly, what business need or problem does it address?

If you already have a solution in place that needs to be improved, think upgrades, cloud migrations, etc., you’ll need to analyze and audit that solution to develop the best path forward.

The technical analysis is a systematic process performed by experienced software engineers and by their expertise in the different programming languages, topics and/or concepts, such as Software Architecture, Quality Assurance, Continuous Integration, Continuous Delivery and Security.

3Pillar’s Javier Trevino explains how we handle the technical analysis process internally. He says, “We perform this analysis as part of our consulting services. Essentially, we start by scrutinizing existing software solutions and measuring their efficacy against industry standards, best practices, and security requirements.”

He adds, “while this process is incredibly detailed and well-documented, there’s room for a lot of variations, as there are countless unknowns that can impact the overall output.

Generally, those unknowns refer to third-party tools and integrations found in any given system as well as any custom toolkits, libraries, and legacy systems.”

2. Put Together a Technical Proposal

After the technical analysis, use your findings to put together a technical proposal—either in the form of a minimum viable product (MVP), proof-of-concept (PoC), or something similar.

Generally speaking, a technical proposal should define the following:

The high-level architecture and technology stack you’ll use to execute the plan. Does this project require new tools? Infrastructure? More storage space? If so, what, specifically, will you need to get the job done?
The Architecture Roadmap and/or Product Roadmap. Your proposal should always include a roadmap, broken into phases. This provides visibility to the leadership team, as well as the developers, QA, and DevOps teams responsible for building and implementing the project.
The initial executable Backlog. This is especially important, as it will guide the development process sprint-by-sprint.

3. Presenting the Software Development Project Proposal

Once you’ve nailed down the specific “what” and “why” behind your software development project proposal, it’s time to come up with a plan for securing stakeholder buy-in.

ID the Key Players:

Who has the final regarding whether the proposal is accepted or not?
Who are the decision-makers you’ll need to get on board first? While the CEO might have the final say, you’ll need to identify the decision-makers that influence the big boss’ decision. Who else is evaluating solutions? Which of those stakeholders is most likely to act as a champion for the proposed solution?
Who stands to benefit from this solution? If you’re proposing a software project aimed at improving the way your organization handles customer data, you’ll want to involve the people who will be using the solution—service, sales, marketing, IT. Ultimately, it needed to be useful for those groups. Otherwise, it won’t generate much value for the organization on the whole.
Who will be involved with the project? In addition to the executive decision-makers and the groups that will be using (or selling) the proposed solution, include the people who will bring the solution to life—development, QA, project managers, DevOps teams, etc.

Consider your audience.

Think about who you’ve defined as “key players.”

Each of these stakeholders is likely to have different goals and a different idea of what the business should be focusing on. The challenge is to get all of these players on the same page. Here are a few things you’ll want to think about at this stage:

Highlight the pain points and paint a picture of how things could be better. What benefits will you unlock by pursuing this initiative?
Avoid communicating with jargon and focus on value. Make sure that you explain why this is valuable in terms each stakeholder can understand. It’s likely that most of the group isn’t coming from a technical background, so stay focused on benefits such as what the proposed solution will enable them to do. That might mean framing the benefits of a new business intelligence tool as a way to understand customers better—thus making marketing and sales strategies more effective. If you’re selling a CFO on the same solution, you might instead focus on how AI-driven insights can reduce costs by providing accurate predictive forecasting.
Does the project make sense in the context of where the business is right now? In other words, does it align with the business strategy and the direction the company is headed in? If not, it may be hard to get other stakeholders to see this project as a priority—even if it stands to benefit the business in a big way. For instance, if you’re proposing a solution that caters to small business clients, but the company strategy is focused primarily on large corporations, it doesn’t matter if you have a brilliant idea; it’s simply not relevant.

Justify the Costs

Software development projects are a significant investment. This holds true in particular if you’re considering a custom build.

Break down project costs in as much detail as possible. You might include estimated costs for the following to help stakeholders get a sense of what they’re looking at in terms of upfront costs:

Will you need to hire new in-house staff?
Do you need to scale up your outsourcing team?
Figure out whether you’ll need some extra hands on deck to get the desired outcome or if it makes more sense for existing staff/outsourced teams to focus on a different set of priorities.
Is an investment in new tools required as well?

You’ll also want to provide a realistic calculation for what kinds of returns your business can expect from this investment. That could mean a financial return. It could also be improving the customer experience, meeting regulatory requirements, or reducing risk.

4. Project Approval Workflow (Nailing the Execution)

It’s important to note that workflows vary based on your business goals, SDLC, and how your team is distributed.

That said, here’s a basic framework for what you’ll want to include at this stage.

Establish milestones and deadlines. Break your roadmap into stages to determine project schedule and milestones. Define deliverables, tasks, and high-level objectives for what needs to happen at each stage. Use story points to estimate how long tasks should take.
ID the Right KPIs. Select KPIs that answer questions about your team’s progress—i.e., you might track productivity by looking at on-time delivery rate or velocity, while looking at error rates can help you understand if your workflow is helping teams deliver quality outcomes—or if you’ll need to make a few changes.
Set expectations. Good workflows ensure that everyone knows what to do—how they’ll communicate, what each person is responsible for, how quality and performance will be measured, etc. Make sure you document expectations in detail and store them in a place everyone can easily access as needed.
Aim for complete visibility. Your project approval workflow should provide complete visibility into both the big-picture plan and the specific tasks associated with each milestone. Ideally, it should function like a map that can be easily interpreted by anyone involved with the project. That way, everyone always knows what’s next—which helps avoid potential risks and eliminates any confusion surrounding next steps.
Define your process for capturing and implementing feedback. Make sure your workflow supports fast feedback loops and routes feedback to the right people.
Automation/tools: Avoid using too many tools. Focus on streamlining hand-offs, creating more efficient workflows, etc. Ideally, you don’t want team members switching between apps.

If you’re designing an Agile/Scrum workflow, you’ll also want to include the following stages:

Review your product roadmap. Essentially, you’ll want to ensure that the product roadmap aligns with the project plan and the organization’s strategic goals. If anything has changed, make sure you update the roadmap with the latest details.
Product backlog. Review your product backlog and update user stories, if necessary. User stories should include clear acceptance criteria, including wireframes if you’ll be developing front-end components.
Set a sprint goal and backlog. The sprint goal represents the big-picture goal teams must accomplish by the end of the sprint, while the sprint backlog is a list of tasks from the product backlog to be completed within the sprint to achieve the big picture objective.
Test at every milestone. Be sure to embed QA testing into the entire process to ensure you catch issues early and often.
Incorporate feedback/validate results (add to backlog). A Sprint Retrospective is a great tool for capturing feedback from a recently-closed Sprint.
Plan the next sprint. Plan next steps and repeat.