No one wants to see their business in the papers for a technical malfunction that brought a critical application down, caused a leak of information, or created liable situations for their business.

However, every day we read a story about how an application went down, or a glitch resulted in a negative impact directly or indirectly to the business.

Many departments have found specific tools that can make their individual arena of expertise easier to manage, but organizations struggle to put it all together.

When it comes to the creation of software for a mission critical application or service, it's the ability to collaborate and share information from inception to release that helps avoid disaster. Knowing that the Analysts have worked closely with the business to create the requirments; knowing that the development teams are in step with the analysts; knowing that testers are working against approved requirments and when requirements change (and they will change!)everyone understands the impact of the change so they can react appropriately. Accurate and up to date information is key.

There are many different ways to exchange information and manage the application lifecycle. Many organziations rely on tools like word or excel, others use a varity of different tools depending on what's deemed best for their specific roles, others still look to an enterprise solution like MKS Integrity to provide a single source of truth.

Deciding which method to manage your application lifecycle really depends on how important software is to your business! Does a missed release deadline impact your business? Does it matter if an application is released with a few bugs? What type of decisions are being made based on the visibility into your application lifecyle. What is your tolerance to software risk?

Take a look at the headlines in today's paper - I wonder if those folks are re-evaluating the important of software to their organizations?

Do you have a story on how you avoided disaster? or perhaps how you fell into a disaster of your own? We'd love to hear from you and your thoughts, comments, or questions on managing software engieering!

Until next time,

Kathy

P.S. MKS hosted a webinar where Forrester ALM analyst Carey Schwaber addresses the importance of lifecycle visibility and traceability in application development. if you are interested - go to: http://www.mks.com/resources/data/multimedia/webinars/instances/the-three-pillars-of-application-lifecycle-management-5

Is your Requirements Change Mgmt Art or Science?

Encarta gives one definition of art as "beautiful or thought-provoking works produced through creative activity". It defines science as "an activity that is the object of careful study or that is carried out according to a developed method". Which category does your requirements change management process fall into? Is your change management process consistent from project to project? Could you rewind history 12 months and describe the exact process to a colleague or easily train a new hire employee on the process? If you answered no to these questions then I would argue that your requirements change management process is an art. I think we can all agree that our goal is to move this process to a science.

Many companies today author and manage their requirements in Microsoft Word or similar tools. MS Word allows for change tracking, permission restriction, comments, etc but does it really enforce change management? These word documents often get emailed around for additions/deletions, approvals, and eventually onto development and testing. How do you ensure that those organizations receive the correct version? Perhaps your organization has taken it one step further and uses Sharepoint to attempt to keep the latest version available. This process may work in principle but what happens when development and testing have already begun and the requirements change? I would still argue that this is art and not science.

Science requires that an organization use a requirements management system that supports a flexible change management process. The ability to define a process, enforce it, and manage that process is critical to increasing the quality of requirements as well as efficiently communicating continuous change. Traditional requirements management tools are not very adept at managing or communicating a complex change management process. These tools offer some basic notifications of change either through concepts such as suspect links or email; however, they do not provide any data as to why the change occurred or whether it was an authorized change. Many of these systems have no concept of a workflow driven process; rather they rely on the users to understand when and where change should apply. This can lead to confusion and rework as systems become large and additional users interact with the same requirements.

The ideal requirements change management solution should allow an organization to develop a workflow based system that may be simple or complex based on the maturity of the organization. Some key functionality areas include the ability to submit a change request into the system that can be discussed and approved or denied based on appropriate roles defined within the system. The change request will have a defined lifecycle that may include stages such as need more information, duplicate, approved, or in progress to name a few. The system should be capable of automation and enforcement by defining the appropriate data that must be entered for a given change request and once processed will automatically promote the change request to the appropriate state and parties. Furthermore, the system should be able to easily link to the artifacts needing change whether that is an entire requirements document, a specific requirement or a subset of requirements. Finally, the system should provide dynamic reports and metrics to deliver statistics concerning requirements churn, outstanding change requests, and overall project status.

Introducing 2 Geeks and a Gal!

Welcome to our blog!

This blog is intended as a place to write about the interesting things we’ve all seen over the years as it relates to software. We want to explore how software is changing how we live our lives, how we work, and how the complexities of software change has introduced brand new challenges in bringing new ideas or new products to market. The tie that binds the three of us together is our experience working at MKS where we all believe there are better ways to build products and to deliver value to the business faster and better!

The main focus of our blogging will be around software innovation as it relates to organizations that rely on application development and IT teams to support the business. For example, a bank that has some fresh ideas on how to offer new programs, a pharmaceutical that is racing to be first to market, or consumer goods that are looking for advances in inventory or distribution management. At first glance, these businesses may seem unrelated to software, but in fact it’s the innovation in software that makes the difference in bringing these products to market.

Let us introduce ourselves:

Geek #1
Marty is a senior product manager that has brought various products to the marketplace with the majority of his career working on the IBMi/iSeries/AS400 platform. This platform is known for stability even as it goes though it’s modernization refresh. Speaking of modernization, Marty with 25+ years experience in this market is now a product owner! He is fully engaged in Agile, working on the most advanced platforms, working in the cloud and uncovering new ways of doing things. As software changes, so do we all!

Geek #2
Lance is happiest when he is knee deep in understanding customer problems and working on the technical details on how to solve them. With 15 years experience working directly with customers he has seen firsthand how software is rapidly changing how we do almost everything. Among the three of us, Lance is our level set – the guy who embraces change strategically for the customers we work with. How can we do better? What makes sense and works best within the existing infrastructure? How can we implement for greater returns in the future, without hurting short term results.

The Gal
Kathy is the optimistic, energetic, idea gal that comes from the sales and marketing side of business. 15 years ago when she started working in the technology field, software was a necessary evil, a cost center, an unknown with lots of risk. The sales and marketing around it was all based on fear, the anxiety, the "What keeps you up at night?" scenario. Today, it's so much more exciting – software is the way of the future, it's how people innovate, it's the differentiator between legacy systems of yesterday and the new frontier. Kathy works with customers that understand technology is a business enabler, that app dev teams don't belong in the basement, but work hand in hand with the business to deliver value faster and better!

We want to hear from you! Please post your comments on how software is changing the way you do business and the challenges you are facing.

Until next time,
Kathy