Wednesday, February 13, 2013

Yes, it is all about the Process …

I’m constantly amazed by the number of people that I talk to within the industry that still run things by the “seat of the pants” methodology.  Let’s acknowledge right up front that operating with no plans is a methodology.  And there are too many organizations that still allow the technology teams to operate under this methodology.

Look at your teams and ask this fundamental question, do you know where your team members are spending their time?  If not, how do you know where to make improvements?  Are they spending their time on activity that is beneficial to the overall goals of the company?  Are they spending their time in meetings that have no purpose?  Are they spending time with busy work that at the end of the day adds no value?

As a consultant, and as a new manager within the companies that I’ve been associated with over the years, one of the first things I do when I walk in the door is to get everyone to start recording where they are spending their time.  I’ve seen companies move from less than 20% productivity on actual approved project activity to over 65% productivity in a matter of months.  Now, I don’t ask for a minute by minute blow – but ask each individual to record when they start and stop working on a particular task.  More importantly, I ask them to record the interruptions.  You know – the simple phone calls or when someone does a drive-by to ask that "simple" question.

If you’ve never done this with your teams, you’ll most likely be shocked at the results.  Some of your best people are getting interrupted so much that they can’t get any work done.  People within the team don’t get enough work assigned and are working on non-productive activity.  By non-productive, I mean work that does not align with the overall goals of the organization and is approved project activity.  Yes, it may be fancy little tool that handles a task done internally, or it may be a change to the routers that someone feels is needed.  However, if it isn’t approved activity, why are they doing it?

The other time waster is the need to do the same task 2, 3, 4 or 5 times because nobody sat down at the front end of the assignment to explain what was really needed.  So the developer, or the infrastructure engineer, tackles the problem, just to find out at the end that they’ve done the wrong thing and the customer is not happy with the results.

Why do we put up with the fact that we are paying someone to do the same thing over and over?  Isn’t it counterproductive to rush something in to production – just to see it fail?  I don’t care if it is a new software patch or a new switch moving in to the infrastructure environment.  If you haven’t put a plan in place on how to assess what it is you’re doing, build, configure and implement in to production – you’re risking on outage for your customers or the fact that you might allow invalid/incorrect transactions in to your system.

Granted, everything comes with a risk and it is valid to make decisions to skip parts of your process if it is a low risk change.  However, the higher the risk, the more important it is that you follow some level of process that includes planning the change, building, testing, planning the implementation and just as importantly, planning the fallback.

Every organization is different and there isn’t a one size fits all model to how you need to manage the processes within your organization.  Your goal as a leader is to evaluate what process is right within the organization you manage and then manage to that process.  Work with your teams to communicate the importance of the process and how it will improve their lives.  Work across the organization with your peers to sell the process and show what the savings will be to the company and how the company should see increase productivity.  You’re not going to make the change overnight, but if you don’t start, you’ll never get the changes put in place.

I’ll leave this with one last question – if you’re not measuring it, how do you plan to fix it?

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment

If you'd like more information on my background: LinkedIn Profile

No comments:

Post a Comment