Monthly Archives: July 2015

The Stakeholer Analysis Phase

Stakeholders

Every software development life cycle from Waterfall to Iterative to SCRUM begins with some form of requirements gathering or analysis phase.   There are lots of names for the requirements phase. Sometimes it is preceded by initiation or project planning phases, but most often it is the first phase of the SDLC. All of these initial phases typically have a focus on the product; its scope, features, architecture, quality attributes, etc. and possibly the resources, procedures, and tools to design, build, and test the product.

The missing and often forgotten activity in these early stages of the development cycle is what I like to call Stakeholder Analysis. While this effort could be considered part of an existing initial project planning or requirements gathering phase, I think this work needs to be called out as a separate phase in the SCM SDLC.   The focus of Stakeholder Analysis is external to the product; it is a focus on the surrounding environment or external aspects of the product. Who is going to use it? Who is going to buy it? Sell it?   Fund it? … and who is going to maintain the code base? This is completely different from the product-centric focus; and it’s only possible to develop awesome, complete, and clearly written requirements after understanding who is out there with a stake in our project.   An incomplete sampling of the stakeholders will lead to incomplete requirements. After all, they are the ones supplying the requirements – making this analysis a prerequisite to the requirements work.

Stakeholder Analysis => Requirements Gathering => High-level Design => …

Stakeholder Analysis belongs in SDLC. As business problems evolve over time, the software requirements need to evolve. What we seem to forget – unless we are calling it out as a separate phase – is to think about which stakeholder changes are happening over time. This activity is not only a periodical check to see if the the currently stakeholder needs have changed, but is also a check for new stakeholders to include. The list changes as business goals and sales targets change. Organization structure changes can also impact our list of project stakeholders.

The success of our projects is dependent upon a review of stakeholders included, regardless of which SDLC type we are following. Checking for changes to the list is an important thing to remember, and calling it out as a separate phase ensures that it will happen.

SCM is Stakeholder Analysis

SCM is Software

Requirements

Software configuration management is a set of business problems to be solved, and the set of programs and processes used to create a solution is very much like a software application project.  We can use the same processes we use for software development to make our SCM system decisions – by treating them just like we treat any other software project – by using a Software Development Life Cycle.

There are many types of software; many categories of software. There is systems software, applications software, network software, and web-ware. The list goes on, including some not so good types of software like malware, adware, and spyware.  Applications software is a set of programs that do the work for users. Users that solve business problems benefit from applications software.

If it’s as easy as following an SDLC, why do we struggle so hard to accept good software design principles as the best way to identify and design our software configuration management problems? Why do we have stubborn, entrenched software engineers squaring off against one another to defend their favorite continuous integration servers, scripting languages, and version control systems?

We know software. We know software best practices. Why then, do we sometimes throw this all to the wind and fight like grade school bullies? Sorry it this offends some of my colleagues; I have unwavering respect for your abilities as software professions and it’s not my intent to insult you. It is my intent to get your attention. If I just sparked a fire in your belly, you know exactly what I’m talking about. Why do we spend so much time convincing other team members to accept the software systems we like – convincing them to accept our way of doing things – yet staunchly refusing to be flexible and learn other ways of working.

When we design a software configuration management system, we need to think like a software engineer developing an application for a complex business problem. That means we start with identifying the stakeholders. All of the stakeholders; including the managers, testers, maintainers, and of course, the developers. Who carries the most weight? Should it be the developers? Should it be the testers? How about the configuration management team?

As with any problem, it’s important for us to see the big picture. What are the requirements? We find these out from the stakeholders for applications development.   We spend time analyzing these requirements. They are best if written down, complete, and prioritized, but that’s not the most important aspect.   Thinking about the problem correctly is the most important thing.  We need to think about the software properties our stakeholders would like to see in the solutions. And we need to know they will evolve over time.

Change management must be taken into account. We need to know what is likely to change and plan for it. We need to lock down the most solid requirements first – just as we do with applications design. What are the relationships between the selected software in the system? What are the major components of the configuration management system?  How tightly coupled are they? What kind of customization has been done?   Do we need any custom plugins? Will they need to be updated as the other major parts of the system evolve?

But let’s back up for a moment. Since we need to plan for changing requirements, we need to start by recognizing that change actually begins with the stakeholders. Designing for change means we’ll be expecting the group of stakeholders to change over time. Who are the stakeholders today, and who will they be next year? Who will they be five years from now?

Without an SDLC, SCM is just another software project doomed to failure.

SCM is Software.