It has been a while since I’ve blogged. Mainly that is due to having a significant role change. In the past year I’ve gone from a cog in the machinery to being the big cog. Dream job? In many ways yes. But the old adage of being careful what you wish for is always something to keep in mind. It might just happen and then you are on a heck of a rollercoaster ride. Now, that’s all I’m going to delve into that piece of history. The main idea behind this blog is about managing multiple projects, people and processes in a diverse and changing system. What is this, you ask? It’s like looking at technology from a distance and up close at the same time. Having a team of diverse and talented individuals who may or may not be in the right role. Keeping stake holders happy and projects on track. A typical day you say. Well if you’ve been there and done that, I would concur.
The future is out there. How you see it and perceive it can play tricks on your plans. Plan? Really, you mean you have to have a plan? How can you plan when you have conflicting projects? One plan is to not have a plan. Yes, I said it. No plan whatsoever. You just react to stuff as it comes up.
How, you might ask, is not having a plan having a plan? Plans are choices and by not choosing to pre-plan your projects you’ve made a choice. So if plans are choices and one was made…voila! A plan. Typically, this type of plan results in chaos. Now that may be fine for advanced mathematics but not really for a business. Not only that you leave yourself open to be blindsided, missed opportunities and generally letting things go to waste. Like not cleaning out the refrigerator, ever. Some of those mystery items in the fridge are truly scary. In business, scary things should be avoided. At least in my opinion.
The clock is ticking. Time is of the essence. Ugh! When does it stop? With luck, never. Perhaps never is too long but you get the meaning.
Now you might be wondering why I’m talking about no plan? Yes? Well, that is the environment I inherited. So, how do you turn it around from an unplanned reactive environment to one where plans are established and executed?
One thing I’ve seen in other environments is the tendency for the change agent to come in with the Great Plan and the attitude of “we’re going to set sail on a new direction, TODAY!”
Having an established plan is wonderful and you do need to have that vision. But it’s a “Vision” not a “Plan”. Why? All the existing employees are used to the old way. People don’t like big changes. Someone coming in with the Big Plan is going to meet a lot of resistance and eventually, the old habits win out. You also end up with grumpy staff!
Eventually you end up looking like…
with all your plans a mess and no traction.
So how does that change?
It depends a lot on your leadership, and the leadership of others. So, keep your vision but you’ve got to do some homework first.
Does that mean you can’t start out right away? Absolutely not.
The first task is to start getting rid of blockers. Perhaps a blocker is an individual. Maybe it’s a process.
Am I saying to “Fire ‘em All”?
No, but you may have to do that unpleasant task more than once. Again, homework!
Staffing changes is an option but before you even go down that route, you have to make sure you’ve identified and acquired the all tribal knowledge that is available.
You may find yourself in a situation where most of the tribal knowledge has already walked out the door. I know this situation first hand. You could have staff on hand that are making the motions but really have no idea how the whole system should even work. If that’s the case, after you’ve ascertained that “Elvis” has indeed left the building then it is time to fire that shot across the bow to let the team know you mean business.
Letting someone go is never easy and should never be done lightly. Homework and documentation. Let me say that again. Homework and documentation.
You have key decisions to make about the role that person occupies. Are you eliminating the role and reducing head count? Are you replacing the person and not the role? A couple of key questions (there are more…) but also you have to make sure that HR is involved with the process and it is done in a legal and professional manner. No kidding! Remember, HR always.
Ok, so maybe it’s a process you’ve got to fire. Huh? Trust me, some of your employees look at their processes as another individual. I mean, it’s like… “We can’t stop doing that! The company will fail if we stop doing that! “That” is the way its always been done. We can’t survive if we don’t do it!” You get it. Homework, again. If you run into this, and you will, you have to have a clear idea of what process or purpose the task fills. Things like repetitive functions that can be reduced to a single or automated step are my favorite.
Reports that go no where. Yes, these animals exist far more than you’d ever realize. I was at a company once where there were dozens of reports generated and sent to a file directory that nobody had read access to. Outside of IT, nobody knew the reports even existed. The staff who generated the reports spent two days every month creating these critical company reports. Critical? Yes, that’s what the department understood. Who knows, maybe it was a former executive who wanted them. Some of the reports were useful and they were kept. The irony was that the ones that took the longest had no current business use. Two days turned into fifteen minutes. Imagine that!
Now it’s time to build all the disparate parts into a functioning whole. The plan? I did start out this mess by talking about a plan… You have to make small turns of each gear that drives the company. Looking where you can remove a cog or, preferably, make the cog smaller so it turns faster. When you take a piece out in the middle of the line, make sure that the other process can move in to fill that gap. This is critical. If you don’t, you simply silo the processes and the dysfunction continues.
The hardest part in all this is having the patience to wait out the small changes. The importance of patience becomes more pronounced when your vision begins to take focus.
Making small changes to address the future vision is an Agile way of looking at business. See, the concept doesn’t just apply to programming. It’s all a series of processes that have to work together to make a whole system.
You can’t be afraid of making the difficult choices, sometimes they are all you have. Typically, if it is difficult the impact is much greater. More when it’s a person choice than a process. Keep in mind though that a process choice may directly affect a person in an unforeseen manner. Isn’t that just a kicker? You get rid of a process making some employees life easier and they quit because you took their process away. Hogwash you say? Unfortunately, I’ve seen it first hand.
Set the vision – you need to know where you are going
Make a general plan – to many details ensure the plan will break. The more detailed, the sooner it breaks!
Increment the change – small changes are easier for the whole to digest. Break up big changes into small parts.
Wait the change – you have to give the change you made time to be adapted to. To many small changes too fast can even be worse than a big change.
Revisit the plan and adjust – Once change has started, new things will come to light that were either not known (a real surprise), the change introduced a new situation (surprising but not a shocker) or you’ve some more time to do some more homework and can better tune the plan (I like this one).
STS1 at Sunset Taken at Cape Canaveral 12 hours before launch. This was a special event provided to the press. A small group was taken out to the gantry for a photo opportunity. It was amazing to watch the Shuttle roll out on the platform. I think the top speed was three miles an hour. It was a beautiful evening in Florida. The night before, the launch was scrubbed due to wind. This was taken with an Olympus OM10 using Kodak Ektachome 64 with a 50mm lens. For this project, I also had 500mm and a 200mm lenses. This image was scanned from an 11×14 picture that was created in 1978.
Light Year Rehearsal, Venice CA 1978
This picture was taken in one shot using an Olympus OM10, Olympus 200 zoom and kodak ektachrome 64 film. Using a long exposure I was able to zoom stop three times during the exposure. Jon was playing while I took the photo. The location was the bands rehersal studio and was lit by a single 100watt bulb and an open door to provide the additional light.
Multnomah Falls, Oregon
This shot was taken in the fall with a Nikon D90, f/16 at 38mm @ 1/6th sec. exposure.
Mount Hood from Parkdale, Oregon
This shot was taken on 10/10/09 with a Nikon D90, f13 at 1/320th sec, at 105mm
As a kid, I love to take things apart to see how they worked. Ok, so this is a radio, you open it up and see things you can adjust. What happens when… Ok, maybe I’m not so far from that kid. I still open things up and make changes just to see the result. That’s how I learn… Now, this short blog is about my approach to problem solving. I’m sure there are others who have written similar articles on similar methods.
Not my concern.
This is my approach and if it bears any resemblance to anyone living or past… Well there is one who has past on that served as the nucleus to my process. That one is JRR Tolkien’s own Bilbo Baggins.
What have I got in my pockets?
When you approach a problem, how do go about it? Do you look at the challenge and immediately see that you have nothing on had that can address the issue? If that’s the case, then really there are three paths to choose from:
Ok, says you, what happened to the fourth option of “just buy new”? If you just buy new, there’s no more problem to solve. That’s always the golden option with it’s own set of issues. So really the above becomes:
What’s interesting is that the amount of effort to “Do the minimum” and to come up with a solution is about the same. Many times, coming up with a solution results in many side benefits. My thoughts on the matter are:
Coming up with the Solution is FUN
Doing the Minimum is Depressing
Speaking of Fun, are Visio diagrams fun? I digress…
OK, now it’s on to “What have I got in my pockets?”
That phrase was muttered by Bilbo Baggins in the Hobbit when confronted by Gollum in the riddle game. Bilbo was simply thinking aloud, trying to come up with an appropriate question for the game so Gollum would lead him out. Gollum jumped to the conclusion that what Bilbo said aloud was the actual question…and the story continued on. If you want to know what happened, read The Hobbit by JRR Tolkien.
What Have I Got In My Pockets
You have a problem/challenge and you need to find a solution. The easiest path would be to just buy new but… there’s no budget. The “do nothing” path isn’t a solution either because what you need to resolve is either failing or has a specific termination date (don’t worry, there are times you can “do nothing”).
Look around – Solution not the problem – Take Stock
A lot of folks try to solve the problem immediately without stepping back to take stock of their situation. The key is to ask “What do you really need solved?”
You need a widget to do something. You are surrounded by tools that can provide you a widget like substance but they all require some resource. The quick folks (sometimes this is the only choice you really have) use a widget like substance that only takes care of 10-20% of the problem.
So you got a 10-20% solution in place and that will tide you over until the next iteration.
You got past the crisis and it was all good right?
Just like ol’ Bilbo and the Ring of Power. He turned invisible, escaped Gollum and had a nifty new invisibility ring. Neat right?
Like any quick solution, if the long term results aren’t looked at and the wizard of knowledge not consulted, the solution could turn into disaster.
This is not to say that quick solutions don’t have a place, they do but unless you are at the 80% mark, there’s still a lot of work to do.
Getting Past 20
Now the diagram looks like:
But that’s not quite it either. It really should look like:
But wait, there is no end! Even if you do nothing, the odds are pretty high that if the issue came up once, it will show up again. So, in my problem solving model, the problems never go away… bummer!
The Stage is set
Up to this point, I really haven’t talked too much about how the problem is solved. I’ve addressed identifying the issue and the possible paths to the solution. Congrats! Step one is done. The whole effort up to this point is to gather information on what the problem is, what is the needed result (immediate and long term) and what can be done now to get the process moving.
When doing nothing is the right answer
I love it when folks get so wrapped up in the idea that there is a “problem” and no one stops to look around and see if it is just groupthink. In this situation, the solution may be to do nothing because that is the right move. Sure, that the issue came up may lead to some interesting facts about the whole process and MAY identify a different challenge that needs addressing but doing nothing about the “BIG ISSUE” is ok.
Why is only doing 10-20% ok?
Often, challenges are really composed of many different pieces and are lumped together into a challenge forest. Maybe all you need is a path through the forest and the rest of the trees can be taken out late when more room is needed. The key is to make sure that the initial items addressed are the immediate blockers. Using the forest analogy, just taking out some random trees does very little if the goal is to make it to the other side.
But I don’t have a chainsaw!
You may not have the tools to quickly cut down the trees right in front of you. But maybe, that’s the wrong action anyway. If you don’t have the perceived right tool, look and see what tools you do have and how they can be applied to the landscape. In front of you, you see trees but if you look to the side, you see a river flowing through the forest. Perhaps instead of an axe or a chainsaw, all you need is a boat and you have a lot of boats sitting around. The river may not be navigable all the way to the final destination but creating a portage around some falls is a lot less effort that plowing through the forest. Less destructive too.
Wrapping it up – What have I got in my pockets
Don’t assume there’s a problem. Take a breath or ten and clearly define what the challenge is and what roadblocks are in the way.
Choose immediate actions to take
Can you take the pressure off? The dam is filling with water too quickly, letting out some water now will keep it from overflowing allow time to build a new dam upstream.
Make sure the goal is the right goal
Remember the forest? Just because a challenge is stated doesn’t mean that the problem to solve is right in front of you. It may be off to the side from a different perspective.
Revisit and revisit and revisit
You’re never done. Job security? Maybe but if you are always tuning a process to make it better, it certainly helps keeping you around.
Facebook, in their ever increasing attempt to make everyone’s information right in your face, enter the “Subscription”.
Drum roll please.
Is this a good thing?
If I were a product or a witty on air personality? Sure
Perhaps even if I were not so witty or even a personality… maybe… if I wanted my words to be broadcast in the new transmission medium called the web…
Ok, it isn’t so new… the web that is…
<queue “The Dark Side of the Moon”> and the lunatics are on the grass…
So get rid of ‘em.
Turn ‘em off…
Step 1: Click on the little down triangle by HOME
Step 2: Click on Privacy Settings
Step 4: Click on the Subscribers Tab link in the How You Connect Dialog Box – by the way, the text here may be different from what you see. First time through it was something like “to change settings in your subscriptions…”
Step 5: Turn off the Subscribers
Happy turn off Facebook socialization day…
Some Links to check…
Facebook Subscriptions: 5 Warnings
As I started down this train of thought…
Visions of the future crowded in…
Then a ditty popped into my head and it’s ok now. I mean, what do you do with a drunken sailor? Especially early (err..lie) in the morning.
This is about Customers and their ways of expressing what they want in contrast to how a lot of technical experts (Consultants, programmers, architects…you name it) interpret those requirements. I mean, it’s all covered with SDLC or Agile right? Personally, Agile seems to me a better approach. As long as the project remains a manageable size. What do I mean by this?
The Grand Example
Perhaps it’s the Grand Illusion? Yes? No, STYX!… To keep this short, I’ll use a very basic example where a customer provided me with an input form and a report/input form. Not really grand…but it will work…
To break it down:
The system definition: Provide a means by which exceptions generated by customers could be recorded and reported on. The reported information needs to be generally available to specific groups and easily maintained. There are two processes by which this information is obtained. A daily review and an on demand special review. Kind of looks like:
The normal path on the left, occurs daily. Exceptions are reviewed, reported and resolved. The “Special Case” on the right only happens on demand and all records reviewed are accounted for. Those with exceptions follow the same basic path as the daily review of exceptions.
The first pass of the forms received looked something like…
An Input Form;
and the combo form:
The Input Form was pretty easy to start with to begin the database modeling portion. It had some selection entries, basic business processes etc. So here’s how that part went down…
You’re right but I’m right… conveying why the physical model is different
The customer in this case was pretty user savvy with databases. Running queries were second nature. ‘splaining how the tables were derived was initially a challenge. Now, the easy approach would be to take the basic assumptions from the initial design discussion, run back to the lab and crank out a prototype. Then negotiate change requests… I didn’t want to do that this time and it was important that the customer fully understood the data design for future support issues.
When is a Model a Model and how do you get there?
One of the bigger challenges I run into is turning the concept from idea to model. The customer always has a vision. The vision is always the right one. It’s just up to you to build it, right? You get there but it’s after cost overruns, delays, and other unsightly events.
Or worse yet, the customer has a vision but so does the architect. Then the customer’s vision is taken as just so much advice and adhered to where convenient. Under that scenario, nobody is happy with the outcome. The customer isn’t happy because the final product is not what they requested and the architect is unhappy because everybody thinks the baby is ugly. Back to cost overruns and hurt feelings.
So, back to the scenario at hand. So far, all that exists are some drawings of a potential system and it’s time for a little show and tell. Now, taking time out to go and create a database ruins the moment and delays the process so here’ s where a prototyping tool like Microsoft Access comes in real handy. Even better if the the customer has a smattering of experience and you can drive them to drink …no… create the structure.
Creating the Model as a basis of discussion
Let’s face it, the best system is define/designed when all parties have a clear understanding of what the point is. Too often have I seen a construction project go awry because the end goal was not understood. Going back to the original request. Had I just ran off with the drawing and a base understanding, the end product would have been something other than requested. Never happens right? Always a clear understanding, yes?
This is where build and discuss is such a great thing and really stresses RAD (rapid application development). I’ve worked with some interesting tools for model driven architecture and they all have their strong and weak parts. Bottom line, use the tool that you are comfortable with and can show results quickly. I like Access 2010 because you have all the parts there and upsizing to SQL is a snap.
Back to the process and the application under discussion. What appeared to me as a report, actually turned out to be a hybrid between data gleaned from the system plus some additional manually input data stored as it’s own unique set. Not only that but a whole other set of requirements came out of the modeling process. It took quite some time but even at it’s rough stage, the final product is already shaping up into something the customer is happy with and can see additional offshoots for future enhancements. This is a much better approach than building some ornately complex system that only you can support. Scary thing is that some folks do this unintentionally.
Structure out of chaos
Software development requires a structure mind, a structured process and a structured result. That works very well when you are creating a finite system of inputs and outputs. For example, a real estate listing system is concerned about the content which is composed of properties. There’s a pretty finite definition of a property and it’s uses.
Where chaos comes in to play has to do with systems that track or deal with variable content. While there is only one way to accurately describe a house in a listing, there are a lot of ways to creatively change or embellish the basic data such that the house stands out or appeals to a specific group. Which is why there list such things as Equal Housing Laws. Some Real Estate professionals were a bit more creative than others…
So how does this come around to Modeling?
When you build the app with the customer in small bits with lots of discussion, the application starts to take shape from some basic building blocks. Asking key questions about values and if those values should be limited to a specific set, yield sub tables with relationships where initially there were none. When you start out, you basically are working from the logical model of the data structure. As the discussion progresses, you can start to build out the physical model for the application. With a tool like Access, you can quickly throw up some basic forms and ask questions like: is this how you envisioned it? What happens when “this” event occurs? How do you see the data changing over time? Experience helps tune your crystal ball for those futuristic type questions but you get the gist.
A fellow by the name of Edgar F. Codd came up with the concept of Normalization in the early 70’s. From there additional contributions were made by Ronald Fagin, Raymond Boyce (with Codd) and C. Zaniolo. From 1981 to 2002 the Normalization front was pretty quiet until C. J. Date, Hugh Darwen and Nikos Lorentzos added the 6th normal form. All of this mainly pertains to relational databases the support transactional data. Why do this? There are lots of good reasons to apply some depth of normalizations. One of the primary ones is data integrity. Normalization through the reduction of duplicate objects within the database enforce data integrity by controlling the objects that can be introduced. Objects can anything from a single field value to the whole database. Another reason is for ease of data updates.
You have a record that describes a house. Some attributes of the record could include roof type, number of bathrooms, kitchen counter type, room floor type and so on. Of these attributes roof type, kitchen counter type and room floor type can be problematic for updates and consistency.
You’ve written the application that only allows certain values. That will keep it consistent right? Sure. That works. But what happens when you decide that “Shake” is not what the value should be? You need to update it to “Cedar Shake”. Ok, that’s simple, just replace all instances of Shake with Cedar Shake. You’re done now. No problem right? Well, what happens if you have a million records and each record has to be inspected for the value of roof type. Does it contain “Shake”? If yes, replace and if no, skip to the next record. A bit labor intensive but doable. I’ll skip the point about going into record and table locks and other nastiness. If you applied some normalization to the database and decided that something with the word “type” is a natural for separate table you’re well on your way.
A simple answer
With the same example, with a “Roof Type” table, you simply have to update the description in the type table. How does this work? With a simple type table you have two items, the Key and Value. The important thing to remember is that keys are immutable. Once created they cannot be changed. The value is updatable and can be modified. In your main table, the “Roof Type” key is stored in the house record. When you display the record, you join the main table with the type table and display the “value”.
Data Type for the key fields has been changed to int type to match the field type in each of the type tables
The final data model looks like:
This way when you update the value in any of the “Type” tables, the change is reflected n the main table without having to update it at all. This means you only have to process one update to affect every matching record. So if your table had a million records, the roof type in question existed on a quarter of those records, you updating once instead of 250,000 times. Make sense to me…
This is just a quick snack on database design and why normalize. Hopefully, there’s enough here that if you do not know what normalization is that you’ll be able to read up more on the process.
A good place to start is this overview of normalization.
A word or two on stuff…
Well, I could have used a different word than “stuff”. I mean, both start with “s”… I’ll leave word substitution to you. Ok, automate stuff? Why automate? What stuff? We like our stuff the way it is, why change at all? There’s a cost and someone with an accounting or business background is going to ask about ROI at some point. What is ROI? Simply put, will I save more (time, money, resources) stuff than it takes to build the stuff.
Why automate anyway???
Now there’s a good question. Why automate?
It takes time
Yup. Can’t argue with the facts. Automation is going to take some effort. As we all know, effort = time. So why spend the time? To get time back, of course… ok that sounded a little harsh and wouldn’t convince any boss that I know of (unless they are an extreme sensor type) to grant the time. <Mission Impossible theme kicks in> Your job, should you choose to take it… really is to look at the problem that you want to solve, come up with a high level plan and then present it. Perhaps, instead of going Ah Ha! (hoosker doo) and running off to the pointy haired one, is to look into the money, planning and training aspects…
It takes money <queue theme from JAWs>
Ok, here it comes, R O I. No, it’s not an alternative spelling for Roy… Return On Investment. This is always a good area to think about even if you’re not going up for some speculative dough or start up cash. ROI’s already been defined but if you need a more specific definition, see ROI in the wiki world…or see it from a different source at Investopedia. So, now that you know, what do you do with it? This is where you need to put ye olde sales hat on, ye olde accountant hat on and crunch some numbers and sell the result. This is also a good spot to ask (called a go/no go decision point) if the “thing” should even be done. There are a lot of tasks in business that can be automated. The automation does make sense. Just make sure you’ve backed up your good sense.
Really, it’s just a jump to the left… planning… The developer in me just wants to cut code and create. Who needs a plan… planning takes you out of the zone… <stop> Put that energy into the creative plan. Then, gack, create the tests to test the plan. Why? You’re going to find holes. The may even be big enough to drive a Humvee through. The time and effort spent in planning will mean that you’ll have a final product that looks like a duck, walks like a duck and even quacks like a duck. Following the “PLAN”, you can employ whatever development life cycle process you use from straight water fall to extreme agile and every iterative step in-between. Some interesting thoughts on planning? See the following references:
|A search of MSDN Blogs…|
It may take training
This one always is a sneaky so and so. What is obvious to the developer just ain’t so with the users who’ll be using the worlds greatest automation solution…
There are a bunch of tools out there to capture stuff and trust me, screen captures are a whole lot more understandable than a bunch of numbered or bulleted steps.
If you’re into the Adobe side of things and budget is not an issue, go with Captivate. Nice tool, gets the job done and pretty straight forward.
Now typically, I’m running on a tight budget and while Captivate is nice, I really like Camtasia. Really this product from TechSmith goes head to head with Captivate and is about 1/2 to 1/3 the cost. For more information see the following:
It takes away flexibility
When you start hearing noise like this, your automate sales job probably didn’t find its mark or you’re choosing to automate the wrong process. Be selective and use the following checks prior to diving in…
- Is it a standard process with little variation?
- Will automating “it” save at least 1/3 the amount of time?
- Can you build it in a way that’s extensible?
- Did you get permission?
While you may be the worlds greatest appdev and automating Excel is a cake walk, do your self a favor and make sure the powers that be are behind your efforts. The worst question to get during the demo is “why did you do this in the first place?” Now you’re on the defensive and you can be fairly sure of two outcomes. One, that you are shoot from the hip kind of developer that doesn’t plan things through and (two) it will be much harder to get future projects funded.
Now, there are those times when you’re working for the pointy haired one and you’re project can walk on it’s own. Take a risk or not? You know best for that one…
What stuff should be automated…
Ok, you may think this has already been covered and you’re right… for other people’s stuff (OPS). But what about your stuff? Hey, you’ve got a little stuff here and a little stuff there…. it doesn’t need to be automated… That may certainly be true. Especially with the changes in coding style, design patterns and the like. Keep an open mind though. There’s a lot that can be done with VS.
We like our stuff the way it is, thank you very much…
There are just some folks who cannot be moved no matter what the ROI is for the change. Sometimes, like that office guy with the stapler, it’s best just to leave be. These tough nuts to crack are good experiences. So, just cause your processor came up with the best new process that, ummmmm, failed to get buy in doesn’t mean you shouldn’t try. Perhaps it wasn’t the process but was more the sales routine that went south for the winter. OK, you’re a dev. You think like a dev. Just play at being a sales guy for a minute. Shoot, you did that as a kid, right? No, you were the kid with the Cray super computer? Sorry… but you might try:
- Get ‘em saying yes… Ask closed ended simple yes questi0ns. Float a couple trial balloons to get the feeling what a “yes” sounds like.
- Feel ‘em out… You’be been talking for a bit (hopefully not too long) and you need a quick reality check. Do be afraid to ask things like:
- ”This sounds like it should save some time, wouldn’t you agreee?”
- o r – a little empathy doesn’t hurt…
- ” Man, shaving off some of this process could free you up on your other stuff?”
- If you’re curios, check out some sales thoughts at
- Thanks for making it through to here. This was a fun blog to write and different from the normal howto stuff. Feel free to share it on…