Skip to main content

Author: Deena Chadwick

Don’t Be An SDLC Extremist!

  • Do you follow process as a Fan or Fanatic?
  • Are you a Loyalist or a Zealot?
  • Are your suggestions Revolutionizing or Revolting?

In the 1980s Pepsi was tired of hearing that people prefer the taste of Coca-Cola over Pepsi. So they came up with the Pepsi Challenge. It was genius, and the results surprised more than those that were blindfolded. Characters in the ads always picked Pepsi, of course, but so did most people who tried it in real life—the sweeter taste was more appealing. So how did Coca-Cola keep their market share and brand loyalty? People continued to have positive feelings toward Cola-Cola, not because of the flavor of their soft drink or because they had a better product, but because they were loyal to the brand.

Related Article: 5 SDLC Project Management Pitfalls & How to Avoid Them

I wish there was a blind taste test for Software Development Lifecycle Methodologies, so people can see that SDLCs are not so different after all!

Diehard sports fans are the same way. When I was growing up the New Orleans Football Team was lovingly referred to as the ‘Aints’ as in “They AIN’T ever gonna make it to the Super Bowl.” So how did the Superdome get sold out Sunday after Sunday? Because Saints Fans were proud of their team whether they won or lost! No matter the projections, the odds, or the score a Saints fan would fight tooth and nail to defend their team.

I wish there was a super bowl for SDLC so we would know which SDLC has the most success.

Heaven’s Gate was an American UFO religious group from California. They believed that the earth was going to be “recycled” meaning wiped clean. They believed that the only way to survive was to leave the planet – that a spacecraft was trailing the comet Hale-Bopp. A large group of followers believed that their way onto this vessel was to leave their human bodies. Over 39 members killed themselves over a three day period, believing the whole time that they were ascending to the “Next Level.”

I am very glad that I do not yet know anyone who is willing to die for their SDLC beliefs!

Though they may not die for it, you probably know a few people who will fight for it. I know people who have argued themselves hoarse and even quit jobs because of their beliefs in a specific SDLC.

There is a psychological reason why people hold so dearly to their chosen methodology. Having a methodology in place reduces the team’s or person’s responsibility when things go wrong. When something bad happens, it is human nature to want to blame something. It is easier to be the victim of the process, than the person responsible for the failure. Identifying a breakdown in process as a source for blame provides closure for past problems, gives a sense of present control, and often eases fear of future failure.

Let’s look at it from a different angle.

  • Has any SDLC claimed that it works perfectly every time no matter what?
  • Do you think any SDLC would grow and be recognized simply by name if it was prone to continuous failure?

I am not advocating No Methodology. After all, a failure to plan is surely a plan to fail. What I am suggesting is that you think of an SDLC as a tool, there are many different kinds and it is up to you to have the right ones available and which one to use for the job at hand.

Commonsensical Project Risk Definition

Definition of Risk

The official definition of a Risk & Risk Management as per the PMBOK Guide is:

A Risk is an uncertain event or condition that if it occurs, has a positive or negative effect on a Project’s Objectives.

I have a confession; the first time I read this it was like reading VCR instructions. I had to read it over and over again just to make the statement sound right in my head. After a while I realized exactly what they were trying to say. Simply put: 

Project Risk is the possibility that something will not happen as planned. 

It really is that simple. So why doesn’t the PMBOK just say it that way? Unfortunately, too many project managers and business analysts assume that something not planned has to be a bad thing. However, change is not always bad. 

If someone you never met before suddenly gifted you a million dollars tax free with no strings attached, it would change your household budget. Would that be a bad thing?

Let’s update the definition just a little to remove the assumption: 

Project Risk is not good or bad, it is simply the possibility that something will not happen as planned. 

Project Risk is never certain. A certainty that something will not happen as planned is called an issue.

By recognizing project risk, project managers and business analysts can attempt to avoid a problem by communication, mitigation and management.

Risk Statement 

So now that we know the definition of risk, how do we state or define a specific risk? 

A risk statement is made up of 3 parts: 

  1. Action or Deliverable – the task or event that is expected to be completed.
  2. A Plan – a defined way in which something is expected to take place. *This does not mean a formal project plan written in Microsoft Project or Excel.
  3. Risk Factor – something that could cause an alteration to the cost, timing, or scope of the action or deliverable.

Here is a basic formula you can follow: 

The _______________ is planned _______________, since _____________ this may _______________.

Example:

The scope statement sign off is planned to be completed by the end of the month, since the stakeholder is frequently called away to another more pressing project this may be delayed or take longer than expected.

Don’t forget to leave your comments below.