Managing Project Scope Within an I.T. Department: Can I Get it in Blue?

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.

Day 1 of my I.T. Career: Welcome to the Job, Young Man!

Oh, I can remember that crisp October day of 1998 so well. So eager to make a good impression was I that I arrived at work at 7:30 AM. I had experienced success at I.T.I., but this was the big time….the big show. It was time to knock their socks off and show them what I could do. It’s amazing how disillusioned a person can be regarding the quality of his/her 9 month education when a $22,000 price tag is attached.

It’s funny how most of us walk into a job assuming that our boss is somewhat knowledgeable of the business and will guide us down the path to success. I was quickly struck by the stench of ignorance. Within 10 minutes of arriving, my boss gave me my first task. She stated that she had a meeting the following afternoon and was to present three sample software applications: a single-tier application, a two-tier application (client/server), and a three-tier application (client/server with a dedicated database server).

I was familiar only with the single-tier design, but I was up for the challenge. I thought that my best approach would be to find a well written book that could guide me along. My search began on Amazon.com. It was great. Within 30 seconds on the site, I found a listing for a book with a 5 star review. As I read the first post, I began to fill with enthusiasm. The poster wrote about the book in glowing terms, stating that it made the development of multi-tier applications fun and easy. I was on cloud 9 until I reached the final statement of the post….”by following the techniques outlined in the book, I was able to get a multi-tier application up and running in less than 6 months”….6 MONTHS? I barely had 6 hours. I thought that there must be some kind of mistake. How could my boss possibly ask me to deliver this in less than a day?

It turned out that my boss was somewhat of a procrastinator. The task had been on her plate for some time but decided to wait until the last possible moment to look at it. After subsequent conversations with a couple of co-workers, I learned that our company had a large team of developers building a multi-tier system for the state of New York. They had been working on it for months and had been experiencing tremendous difficulty.

I communicated this information to my boss and the request was subsequently withdrawn…..as was my boss within a matter of weeks.