Managing Project Scope Within an I.T. Department: Can I Get it in Blue?
.jpg)
The number one rule of project requirements definition is to get people to sign off on the requirements, thereby acknowledging accountability. Without accountability, you have ZERO control. It’s amazing how many people suffer from amnesia when asked to sign off on the product features they request. Based on the resistance, you would think that they were being asked to sign over their souls to the devil.
I must say that over the course my career, nothing has generated a higher level of aggravation than to hear people change their minds regarding the desired functionality of a software application. When you work for a software development company, it’s less of an issue, as it is normal practice to define the specifications and have the client sign off on them before beginning development. That’s not to say that the process runs perfectly with this type of structure; it doesn’t. However, when you develop software for in-house use and the senior executives treat your department as “overhead”, you’re in a vulnerable position. If there are no repercussions for changing one’s mind, one’s mind will often change. As I look back at my time spent developing in-house software applications, I can’t count the number of times an individual requested a certain piece of functionality only to change his/her mind a week later. You find yourself in a non-stop design mode, unable to proceed with confidence through the development and testing phases. A formalized change control process was unheard of in this particular organization. Another problem occurs when the stakeholders attending your meetings constantly change. Last week, Shirley provided her recommendations for a specific screen design. However, Shirley is on vacation this week down south and Janice is representing their group. To no one’s surprise, Janice expresses an interest in a screen design different than the one proposed by Shirley. What do we do? Maybe we wait until Shirley gets back so that she doesn’t feel that her opinion was disregarded. Next week, Shirley attends the meeting, but cannot even remember what she requested, as her primary focus is on her tan, which appears to be fading since her return.
See the challenge? A simple sign off significantly reduces the risk. A person is less likely to change his/her recommendations if you have it in writing because of the effort involved in justifying the change (via a formal change control process).
Another problem that exists for software development departments that develop applications for in-house use is the sheer volume of requests that are received. In one of my stints as an analyst, every business unit within the organization had ideas for software applications, many of which were identified as vital for business growth. The software development department was unable to satisfy all requests. It seemed like there was enough work to keep my grandchildren busy, long after my retirement. Things eventually came to a head. As a means of prioritizing projects, the working relationship between the I.T. software development group and the rest of the organization was modified. From that moment on, all requests for software applications required a formal business case. Time and cost estimates were provided to the business unit, after which a decision was made on whether to proceed. Many people will pound their fists and stomp their feet in their attempt to convince others of the project feasibility and the potential return on investment. After you slap on a $500,000 price tag, they’re not so sure. As the days passed, the number of withdrawn project requests grew significantly.
I must say that over the course my career, nothing has generated a higher level of aggravation than to hear people change their minds regarding the desired functionality of a software application. When you work for a software development company, it’s less of an issue, as it is normal practice to define the specifications and have the client sign off on them before beginning development. That’s not to say that the process runs perfectly with this type of structure; it doesn’t. However, when you develop software for in-house use and the senior executives treat your department as “overhead”, you’re in a vulnerable position. If there are no repercussions for changing one’s mind, one’s mind will often change. As I look back at my time spent developing in-house software applications, I can’t count the number of times an individual requested a certain piece of functionality only to change his/her mind a week later. You find yourself in a non-stop design mode, unable to proceed with confidence through the development and testing phases. A formalized change control process was unheard of in this particular organization. Another problem occurs when the stakeholders attending your meetings constantly change. Last week, Shirley provided her recommendations for a specific screen design. However, Shirley is on vacation this week down south and Janice is representing their group. To no one’s surprise, Janice expresses an interest in a screen design different than the one proposed by Shirley. What do we do? Maybe we wait until Shirley gets back so that she doesn’t feel that her opinion was disregarded. Next week, Shirley attends the meeting, but cannot even remember what she requested, as her primary focus is on her tan, which appears to be fading since her return.
See the challenge? A simple sign off significantly reduces the risk. A person is less likely to change his/her recommendations if you have it in writing because of the effort involved in justifying the change (via a formal change control process).
Another problem that exists for software development departments that develop applications for in-house use is the sheer volume of requests that are received. In one of my stints as an analyst, every business unit within the organization had ideas for software applications, many of which were identified as vital for business growth. The software development department was unable to satisfy all requests. It seemed like there was enough work to keep my grandchildren busy, long after my retirement. Things eventually came to a head. As a means of prioritizing projects, the working relationship between the I.T. software development group and the rest of the organization was modified. From that moment on, all requests for software applications required a formal business case. Time and cost estimates were provided to the business unit, after which a decision was made on whether to proceed. Many people will pound their fists and stomp their feet in their attempt to convince others of the project feasibility and the potential return on investment. After you slap on a $500,000 price tag, they’re not so sure. As the days passed, the number of withdrawn project requests grew significantly.
No comments:
Post a Comment