Click here to Skip to main content
14,976,584 members
Articles / DevOps / Agile
Tip/Trick
Posted 2 May 2021

Stats

1.9K views

Convincing Stakeholders of Necessity of System Creation and/or Code Changes

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
2 May 2021CPOL2 min read
7 Step Outline will help you communicate quickly and clearly to team about System Creation / Code Changes
Follow this 7 Step Outline to provide others with explanation and understanding of why the team should implement your System Creation or Code Changes.

Introduction

While reading numerous books on Proposols, Project Planning and Project Management I came up with this outline that can help you quickly create and communicate necessary details to your teams.

Developers often forget how important it is to communicate and convince the Business Team that System Creation and Code Changes must be made.   Following the short outline may help you to create a sound argument which will convince the Business Team to fund and/or allow the project to be taken on.

Background

A lot of this outline comes from reading and re-reading the very good book: Writing Winning Business Proposals, Third Edition [^]

7-Step Outline

Here's a quick 7-Step Outline you can use to create a presentation or document when you need convince Stakeholders that a Code or System change should be implemented.

  1. Describe the current state (of system or code) and what is missing.
    • The audience needs to know why you are asking for the change.
    • Make sure your Problem Statement is clear. The Problem Statement is often ignored or is explained very unclearly and causes the audience to fail to understand the importance of the project.
  2. Summarize the desired state and why it is important.
    • Again, the audience needs to know what advantages which will arise from implementing the change.
  3. Provide steps to get to desired state.
    • This will allow your audience to get an idea of the scope of the project (and help them understand if it will takes hours, days or years to implement the change).
  4. Why you (or your group) are the right team to get to the desired state.
    • How much history you have with your audience will determine how much info you need to provide to convince them that you are the right person or team to do the work.
  5. List Challenges to achieving the desired state.
    • Provide a list of items that could hinder the team (or cause the project to fail)
  6. Provide feasibility of achieving desired state.
    • Provide monetary and time estimates and list of resources needed so audience can determine how likely it is that everything can be pulled together to achieve the desired state.
  7. Provide a convincing call for others to drive towards the desired state.
    • After you've put everything forward, make strong request that the project begin so the problem can be solved.

If you apply this outline as you attempt to create your documentation or presentation, it will help you create a fast / short document which will provide the necessary details so a good dialogue about the project can begin.

What Do You Think?

What process do you use to communicate and convince your team that a particular system or code changes should be implemented?

History

Keep a running update of any changes or improvements you've made here.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

raddevus
Software Developer (Senior) RADDev Publishing
United States United States
Roger has worked in IT for over 25 years in numerous roles (Technical Support, Quality Assurance, Capacity & Performance Engineering and Software Development).
During that time, he has recognized that software often just becomes another layer of work that the user has to wade through.
Sometimes technical documentation is like that too: so confusing and complex that it wastes developers' time.
That's why when he writes his books like Programming Windows 10 Via UWP and his articles (Practical Electronics For Makers) he strives to explain things in the shortest available space with the simplest language possible. Often that means, writing in a tutorial style with numerous images to help guide the user.
He believes the best guiding principle is Einstein's famous quote: "Everything should be made as simple as possible, but not simpler."

Comments and Discussions

 
-- There are no messages in this forum --