Click here to monitor SSC

Phil Factor's Phrenetic Phoughts

Simple-Talk columnist
The wilder shores of Transact SQL    Phil on Twitter   Phil on SQL Server Central  Phil on BOS

Doing things- The Manual

Published Thursday, March 08, 2007 4:20 PM

In the past, in order to get something done, you did something. This normally involved taking off your jacket; possibly even loosening your tie. It could be you needed gloves and goggles, maybe a mate to hold your tools, but generally, you got on and did it.

Now, dear me no.

Steps in doing something

  1. Attend 2 day training course
  2. Submit signed statement of commitment
  3. Engage Stakeholders, communities, agencies, and other staff
  4. Establish a task group
  5. Carry out an audit and risk assessment
  6. Identify priorities and targets in line with key policies
  7. Collate Baseline Data
  8. Complete and submit an action plan, itemising key objectives
  9. obtain mangement signoff for action plan
  10. meet with management team as appropriate
  11. Attend network meetings
  12. Review and evaluate
  13. Return monitoring forms to your supervisor
  14. Return updated action plan as appropriate
  15. Prepare for doing something
  16. Do something
  17. Compare new data with baseline
  18. Final report to management teams for signoff

Doing Something the People Way

Whilst doing stuff, you'd be well advised to utilise a methodology known as 'People Side of Change'.  It offers a 'best practice framework for identifying and managing the five critical success factors in any change'.
 

  •  Thinking, planning and doing the right ‘people things' throughout your change initiative
  • Building and sustaining the right levels of commitment to make your change work
  • Understanding what people issues could be enablers or blockers
  •  Focusing on those issues that are critical for the success of your change increasing the capacity for benefits realisation
  •  Applying sound change management principles

Five things that are very important when taking a 'people side of change' approach to doing something.

 

Comments

 

AreEyeEkks said:

I shall attend to providing you with extra steps... just as soon as I have attended a 2 day training course, submitted a signed statement of commitment, engaged....
March 8, 2007 10:41 PM
 

WilliamGrene said:

Are you confident that you've identified your key procedures?
March 9, 2007 2:22 AM
 

Gerard said:

And what about the 'cool off period'?  You'll need several of those.
March 9, 2007 8:08 AM
 

KeithRupert said:

Since making changes exactly as spec'ed the first time never gives management the expected results, shouldn't steps 12-17 be in a loop?
March 9, 2007 8:55 AM
 

PJ said:

Having done the training course for how it should be done (a.k.a. ITIL Foundation) I think you've missed out some steps of the change procedure including getting it working on development servers, then transferring it to test servers, getting the user to actually test it on the test servers AND sign off that they've done so, getting it through the Change Advisory Board, getting various signatures required to put anything on live systems, getting the server manager to do the necessary to get it live, getting the sources into the CMDB......
At least with the management signoff you actually got the business to take ownership of the project!!
March 14, 2007 7:29 AM
 

Granted said:

Didn't you miss performance testing, seperate from and independent of functional testing?
March 16, 2007 8:49 AM
 

Patrick Index said:

Once a friend told me he had decided to stop "delivering projects" as no one else was delivering anything so why should he?  It was just too much grief.  He worked for a large Investment Bank (permie of course).
March 16, 2007 9:11 AM
 

WebMister said:

Whenever anybody asks me how a job is getting on, and I've done absolutely nothing, I just look enthusiastic and say 'Fine, I've almost completed an in-depth assessment of baseline criteria, and established the contingency parameters. I have made good progress in gathering a consensus of the requirements from the stake-holders, and will soon be executing the action plan in line with the key objectives.'
It never fails to impress.
March 16, 2007 9:47 AM
 

JRHE said:

Based on my current experience, step 8 should itself be an iterative process - as in draft plan 0.1, 0.2, 0.3 leading (ultimately) to sign-off version 1.0. Subsequent morphing from v1.0 to v1.whatever is covered by step 14, I think.

BTW step 9's "mangement signoff" is one of my regular Freudian slips too.
March 22, 2007 12:42 AM
 

JacobDickinson said:

Regardless of the obvious fact that the process is intended to prevent anything from being done, some "when worlds collide moment" will come, when someone asks for an estimated percentage completion. A simple update of Zeno's paradox can provide these estimates on demand. It depends on a few assumptions:

1. As 12-step programs point out, recognizing that there is a problem is half the solution. We will assume that a project exists to address a problem; therefore its existence is equivalent to recognizing a problem.
2. Physics has "time's arrow": although it's easy to move in both directions in other dimensions, we seem to be able to only move in one direction in time. We will avoid depression and alienation, and the risk of being seen as whiners, by making the analogous assumption that we only move closer to project completion, never farther from it. "Completion" may be re-defined, but every day of effort brings us closer to it.
3. We're never really done. At some point we may have to stop, but it's not because we're done.
4. Projects have a fractal nature, growing more complex as one examines them more closely. Projects are also beset by randomness. Therefore, we cannot truthfully say how much closer to completion we have gotten since the last time we reported progress. A random answer, being free of subjective bias, is at least as truthful as anything we might come up with.

These assumptions lead us to an approach that is easily implemented in a few rows of a spreadsheet:

1. When the question first arises, the project is at least 50% complete, since it exists to address a known problem. This is always a very encouraging thing to consider.
2. Each subsequent time the question is asked, percentage completion increases to the sum of the previous percentage and a random number times the remaining percentage. We always make progress, so the random number must be greater than zero, but it's impossible to honestly say how much progress we've made, so we defer this to a random number generator, or to a more complex approach, incorporating some kind of probability distribution. We never finish, so the random number must be less than one.

If P is the percentage completion the last time the question was asked, or project status was reported, P' is the latest percentage completion estimate, and R is a random number (0 < R < 1),

P' = P + R(100-P)
April 18, 2007 1:20 AM
 

The SQL Server Thought Police said:

I never do things, I generally just establish frameworks, and act as a facilitator.
April 27, 2007 7:10 AM
You need to sign in to comment on this blog
<March 2007>
SuMoTuWeThFrSa
25262728123
45678910
11121314151617
18192021222324
25262728293031
1234567
Migrating from OCS 2007 R2 to Lync: Part 4
 Having migrated the rest of our users and legacy resources across, and start getting ready to... Read more...

Automated Script-generation with Powershell and SMO
 In the first of a series of articles on automating the process of building, modifying and copying SQL... Read more...

Seth Godin: Big in the IT Business
 Seth Godin has transformed our understanding of marketing in IT. He invented the concept of 'permission... Read more...

Using SQL Test Database Unit Testing with TeamCity Continuous Integration
 With database applications, the process of test and integration can be frustratingly slow because so... Read more...

Converting String Data to XML and XML to String Data
 We all appreciate that, in general, XML documents or fragments are held in strings as text markup. In... Read more...