Phil Factor's Phrenetic Phoughts

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

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
Virtual Exchange Servers
 Microsoft now supports running Exchange Server 2007 in server virtualization environments, not just on... Read more...

Virtualizing Exchange: points for discussion
 With the increasing acceptance of the use of Virtualization as a means of providing server... Read more...

Encouraging .NET Reflector Add-ins
 Jason Haley is well-known for the resources he's provided to developers who wish to extend Reflector's... Read more...

Using .NET Reflector Add-ins
 .NET Reflector by itself is great, but it really comes into its own with the help of some add-ins. Here... Read more...

Unique Experiences!
 You'd have thought that a unique constraint was an easy concept - Not a bit of it; it can cause a lot... Read more...