Tools and the SDLC - Let's Make a Change!

How do you transition from one tool to another or make the decision to change the type of development paradigm that your teams are using?  I'm not going to pretend it's easy, nor am I going to pretend that I'm an expert at it.  But, I have been through several of these across different organizations and the path is similar.  What I'd like to do is share some of the insight that I've gained throughout my career and ask that others provide feedback on what they've seen and experienced.

I've seen organizations shift their development processes back and forth between very informal processes, to formal processes, to something in the middle.  Sometimes adding/changing/removing processes or tools, sometimes swapping out the entire paradigm by which the team operates.   All of this is being done in the name of improving time to market, increasing quality and/or improving the productivity of the team members.  Admirable goals, no doubt.  In fact, consultant organizations have popped up over the years that specialize in taking teams to specific development paradigms and switching the entire tool sets used across the entire lifecycle.  This is not something that is done lightly.  There is usually a loss of productivity through the transition period and an outlay in real dollars as the organization trains entire teams on the new paradigm.  Market opportunities are impacted as teams shift to the new paradigm and the potential to fall behind the competition is real.

Software Engineering is both an art and a science.  The science part is the syntax - this is straight forward and understood and can be taught.  In fact we have excellent resources - both formal and informal - that allow anyone interested in getting in to software development to learn.  On-line tutorials, books, free on-line courses, paid on-line courses, high school courses, college courses, and seminars.  Along the way, at any level, prospective and experienced developers can get assistance via dedicated web forums, videos, and sites that hold sample code.  If you need help learning how to code a particular language or a specific function, you can find help on the web. I still remember my amazement back in the late 80's when I posted a development question up on a early portal and received an answer within a matter of hours from someone half-way around the world.

Project Management is also both an art and a science.  The science part is managing the defined process and set of artifacts.  Knowing when certain activities need to be completed.  Understanding when a team member or portion of the team needs to complete specific artifacts.  Managing the Risks and Issues.  Understanding when to communicate to the team, individual team members, across and up through the organization.

The art of Software Engineering and Project Management is the individual.  Put two engineers in the same room to solve the same problem and you will invariably get two different answers.  Assign two different Project Managers to the same project and they will drive results differently - one may be more of a driver - managing the process by proof; the other more of a expressive - using relationships to primarily drive the process.  Making software development work is not always taking preexisting components and placing them together.  It is not like building a prefabricated home.  It is knowledgeable people understanding how to finesse the tools and the processes to move the ball forward.

Development Paradigms and the Development Lifecycle (SDLC) are the sauce that brings order to the development process.  Attempting to provide the pieces needed at the appropriate times to allow all parties to be satisfied.  Moving from no development process or paradigm to a structured paradigm can be difficult - trust me, I've been there, done that.  However, moving from one structured paradigm to a different paradigm is often worse.  When there was no process to follow, getting someone to create a specific artifact or to follow a specific process is an effort, but can be done.  Getting someone to change the way they create an artifact or to stop creating the artifact altogether is tough.  All of a sudden, fifty people will show up to explain why they need the artifact the way that it is today, or that by not producing the artifact, you are going to break 100 different things across the organization.

Fundamentally, I guess I've always asked for feedback on the processes and tools that are used within the organizations that I'm leading.  Yes, I want to bake in what we are doing, but I also want feedback, and if I can be convinced of the value, I'll work with the teams to make the changes and to drive overall improvement.  Here are the ground rules that I ask people to consider before recommending changes to the processes, tools and the overall development paradigm that we use:

1. How will this impact the customer?  Everything that we do must be in the context of our customers.  What's the worst case scenario if we suddenly transition from the way we currently do something to the new way being proposed?  What are the perceived benefits of making the change?
2. What does this do to our quality?  Yes, this is related to the first item, but stands alone on the overall merits.  Does the change allow us to fundamentally alter the quality equation?  Can it reduce the efforts needed to validate existing quality?  Does it provide additional quality measurements that are not used or possible today?  Does it expose us from a quality perspective and unintentionally add risk to our systems?
3. What does this gain us against our competition?  Does it allow us to leapfrog with some feature set or capability?  Does it alter the balance and allow us to take advantage of competitive weaknesses?
4. How does this impact the flow of data through the organization - does it reduce the quality of data, does it reduce the number of places data is stored, does it reduce the number of times data is entered through various systems?
5. Can the change provide a significant reduction in the time it takes to move through the overall lifecycle and improve time from concept thru delivery?
6. Does it impact our security stance?  Does it improve or decrease our ability to secure our intellectual property (IP) and the data held within our systems?

These are not conversations based on the concept of - hey, I found this great new tool on the internet and played with it at home, so I want to start using it at work!  The dialog must cover the above points and we must also take in to consideration the impact across the team.

I can't afford to change tools, languages, processes or artifacts on every project that runs through the organization.  That said, I'm always interested in having a discussion on ways we can make positive changes that can reduce our internal efforts, improve the security stance of the organization, drive better quality within the products we build, and reduce the overall time to market.

As it sits today, I have people trying out different processes within the way that we run our project meetings.  I have people making recommendations on new tools that we can use within the lifecycle.  Team members are also making recommendations on changes to some of the artifacts that we use.  Will all of these changes make it in to production - probably not.  Will some - I hope so.  Over the last six years we've made significant strides that have allowed the organization to dramatically increase the number of projects being worked as well as the quality of products being delivered.  Now we must change to meet the future needs of the organization.  We must continue to innovate and deliver solutions that make a difference.

When and how do you allow changes to be made to your overall lifecycle, the tools that you use and the artifacts that are generated?

Tags: Project Management, SDLC, Project, Management, Project Manager, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development, Paradigm

For more information on David L. Collison: LinkedIn Profile