SDLC Automation Solution, (release management) Henry Ford style


What is the project approval process that your project management office (PMO) or project managers go through for each project? How do they get projects approved, estimate and plan the appropriate level of effort, or collect status reports? These are important questions to answer and the most important may be how does the project manager convey information and manage client expectations?

 

sdlcmanager.pngNo matter the catalyst most projects are initiated to either enhance or repair current functionality to existing applications or systems. This can range from a capital project or upgrade request all the way down to a patch-fix release initiative. Most projects start out with a rough level of effort and cost which is then compared to business need—and the project is typically out of date before the ink is dry on the project plan. This is especially true for companies that have to deal with either public or private regulatory entities. For these organizations the simple process of kicking off a new initiative/project can be mired down by something as simple as the approval process. In some cases it takes longer to initiate a project than it does to design, build, test and implement applications enhancements.

 

If your team has already implemented the agile methodology some of these problem areas of have naturally been addressed by the process itself. However, most of these issues sometimes called “roadblocks” can make a typical burn-down log graphic look like the drawing of the tracks for the runaway train at Disneyland.

 

Measuring success one teaspoon at a time

 

By looking into the concepts and ideas of handling the complete SDLC process from initiating the project through completion you can only measure success in two ways:

  • First—how much quality work did you get done in the allotted time? There is really no point in asking this question other than sun setting the application.
  • Second—how much time did it take to implement a product? Unfortunately, this will   more likely only meet the minimum client expectations.

 Henry Ford once said “You can have a model T in any color you like as long as it’s black”

 

I believe that the Software Development Lifecycle (SDLC) is similar to automobile production. Every frame of an automobile is placed on the same assembly line. With this production model, each vehicle frame has the potential to be a top-of-the-line luxury car or a bare-bones economy model automobile. If you have two versions of the same car model placed on the assembly line the automated process simply adjusts to accommodate each variation. This makes each car  a customized vehicle built to the specifications of the detailed requirements.

 

ford.jpgLet’s pretend we could go back in time 100 years, l and have the IT department in charge of automobile manufacturing. Each assembly line would have two to three different conveyor belts for each version of that same model vehicle being manufactured. Each conveyor belt would start and stop at the beginning and end of each department/trade and each vehicle would have to be pushed to the next conveyor belt manually. Once the automobile frame was put in motion in the modifications or change requests would add weeks or months to the finished product. Is this truly the most effective way to get unique changes?

 

This makes me wonder why when an automobile frame is placed on the assembly line it’s merely happenstance that distinguishes its price tag from another by the time it reaches the end of the assembly line.

 

Most IT organizations come up with processes, strategies, and a methodology which is based on the size and visibility across the company. I’ve been to several companies that have three or more SDLC processes and they are typically based on the aforementioned visibility and/or cost. It like to call this the SDLC catastrophic failure scale. I often use terms that sound like they belong in a beer commercial (lite and ultralight) rather than describing IT development process.

 


I intend for this blog series to inspire cooperation and automation across every aspect of the IT process and to eliminate the waste of valuable time and money on manual intervention. Project and release management play a vital role in eliminating these areas of waste and promote real time (automated) communications. This will help to remove these frivolous roadblocks which tend to go nuclear if not identified early in the process. Release management manages and monitors the conveyor belt while monitoring the overall application quality:

 

  • ALMCCCC.pngApplication Management—this is the concept of looking beyond a project or initiative and looking at the application as a whole. I described application management as the understanding of original business needs, implementation, and the accumulation of information of an application via initiatives (projects) up to its current state. You’re probably thinking that I am making an attempt to describe a new type of job along the lines of application historian. I am not describing a job but a capability of automating the progress of the project tracking as well as the capability monitoring and applications health over time. It’s tough to remember why an application or business rule is implemented unless some sort of automation has been implemented to monitor and manage this information. In other words, the ability to automate the process tells you when and how a business rule has been changed or modified and what the impact of that decision is. Application management also includes application integration management, sharing information across initiatives and management process.
  • Change Management—also called the “project killer” from the standpoint that if change management isn’t well documented and managed, projects, timelines and cost will quickly spiral out of control. This will then result in diminished client expectations by the lack of change control. Processes that could be easily automated within the change management process include: time, priority and risk analysis.
  • Issue Management—each phase of the SDLC process has its own version of issue management. For example: project management typically has an Excel spreadsheet which is typically called the issue log which contains status and priority along with a detailed description and comments section. Business analysts typically track change under “change controls” with some type of scope management tool—again typically Excel. These two have similar entities and processes to issue log that is characteristically found and managed only during the design phase. Development looks at issue tracking in the form of task management which may use the myriad of tools from PowerPoint all the way to source management system. This is typically described with a description, priority, status and finally a comments section. Let’s not forget the testing groups defect management system which typically boils down to a status, description, comments and priorities. While all these different types of issue management systems contain similar entities, this information is typically not shared across groups or teams within the same project. What if the test group finds a defect with all of the information needed to fix the issues and the development team sees the same information as a task. They then realize that this would be considered an enhancement and then the system automatically generates a change request. Now the business analyst contacts the business group as part of the change control process and at the same time the project manager is made aware of the possible roadblocks and can estimate time and cost of the change control. This is all possible within minutes of the defect being found instead of weeks or months.

 

The process that we have just looked at involves the three key areas to successfully manage projects. We took a closer look at the application, managing the change process as well as monitoring and managing issues. Remember these are often considered very mundane and tedious processes within the SDLC process—which is why automation is vital. In my two previous articles, I talked quite a bit about the overall strategy. Today I attempted to get into a little bit more detail (still only scratching the surface) of the release management process—which includes project management. You may have noticed that I didn’t go into one of the key areas which is KPI’s and the reporting process; which are important to the release management process. I decided that I didn’t want to write a book and I think it is best that I keep some information for future articles.

 

I would be interested in hearing from you the readers about how you address these three key areas for release management today. I want to know if you automate these processes or keep them manual—and if its broken what do you do to fix this ongoing nightmare.

 

This series of articles are based on a presentation given at HP Discover Las Vegas. I encourage you to view my slides from this presentation here. The presentation addresses the process of developing software is a lean development environment with shrinking timelines and growing stress levels.

 

Other Article in this series:

  1. Learning from the past to improve the SDLC process of today
  2. SDLC Automation Solution, (Overview) Henry Ford style

 Look for future blogs on the SDLC Automation process:

  • SDLC Automation Solution, (Design management) Henry Ford style
  • SDLC Automation Solution, (Development) Henry Ford style
  • SDLC Automation Solution, (Testing) Henry Ford style

Backstage Barcelona banner.png

 

Thanks

@wh4tsup_Doc

BlogBB.jpg

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Michael Deady is a Pr. Consultant & Solution Architect for HP Professional Service and HP's ALM Evangelist for IT Experts Community. He spec...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.