Monday, December 30, 2013

My top 3 "reading list" for eating healthy and being healthy in 2014


OK, first things first. These aren't NEW books, but I don't think we need NEW I think we need GOOD.  This is my road tested top 3 list from the last year, so if these worked in 2013 they will work in 2014. I'm linking to Amazon since I find my experience with ordering books from them to be superior.



Simplest Advice Award is to "Drop the refined sugar."


Watch this video.  Nope it isn't cats people pull up your comfy chair and settle down for a smart hour long intellectual presentation that will cause you to re-think sugar.Sugar the Bitter Truth: http://www.youtube.com/watch?v=dBnniua6-oM Kind of makes me thankful for endocrinologists with an axe to grind.



There is even a book about the video if you insist on watching it in paperback (Mom and Dad I'm talking to you). The Real Truth About Sugar-- Dr. Robert Lustig's Video Lecture "Sugar: The Bitter Truth"





Most Audacious Title award goes to: Never Be Sick Again by Raymond Francis.  


Yeah the title was a real turn-off for me as well, but the biochemistry and advice seems to make good sense.  If you are easily turned off by writing style you may need to push through a bit of "I can't believe everybody else is wrong."  But I'll tell you, the content is well worth the read. Kudos on content, the title didn't help with credibility.  The jacket sums it up well; "There is only One Disease: Malfunctioning cells. All cell malfunction can be reduced to Two Causes: Deficiency and Toxicity.
By addressing the Two Causes through the Six Pathways (Nutrition, Toxin, Psychological, Physical, Genetic, Medical) almost all disease can be prevented or reversed."
Never Be Sick Again: Health Is a Choice, Learn How to Choose It




Longest Read award goes to: Eat Drink and be Merry 


by Walter C. Willett, M.D., with Patrick J. Skerrett
Walter. Willett, , is chair of the Department of Nutrition at Harvard School of Public Health and a professor of medicine at Harvard Medical School.  You can learn more here:
http://www.health.harvard.edu/books/Eat_Drink_and_Be_Healthy  
Grounded in science and closely associated with the research of the Harvard Medical School, this book is a good thorough read for understanding health and nutrition.

Eat, Drink, and Be Healthy: The Harvard Medical School Guide to Healthy Eating



To your Health!
Greg.

Friday, November 15, 2013

Centralized vs Decentralized work and the impact on Quality

"Centralized vs Decentralized"
These two terms explicitly describe "where" an activity takes place.

I think sometimes teams might implicitly choose to use these two terms as euphemisms for "performed in a standardized manner by experts" versus "performed with high variability by a crowd".
Such an implicit meaning is not necessarily fair because there are both pros and cons to each approach.

Expert processing is expensive with limited availability but more likely to be consistent.  
Crowd processing is harder to control (activity and outcome) but ultimately quite cost efficient if it works.

I know sometimes our team is  troubled by the “variability” in distributed activity. (e.g. Do project owners get their software listed in the software list, do change owners complete risk scores etc.)
And I know sometimes we are tempted to switch models and “centralize” to address these issues.  But time and money are short for our Quality Improvement team and centralization and the transformation to centralization is expensive.

While that may be an appropriate solution, it isn’t necessarily arrived at after a careful assessment of all of the alternatives.
For example, there are ways to leverage the “bandwidth” of the crowd without necessarily sacrificing quality of results.  i.e. While not controlling activity we may find appropriate means to positively affect outcome, whether through support or appropriate feedback loops, or gates etc.

It makes me think that I want to invest in my own learning about how to influence the outcomes, rather than necessarily taking over the work involved in the activity…


Here is an interesting excerpt on 3 kinds of “crowd wisdom” found in “disorganized decisions”


Types of crowd wisdom[edit]

Surowiecki breaks down the advantages he sees in disorganized decisions into three main types, which he classifies as
·         Cognition
Thinking and information Processing
Market judgment, which he argues can be much faster, more reliable, and less subject to political forces than the deliberations of experts or expert committees.
·         Coordination
Coordination of behavior includes optimizing the utilization of a popular bar and not colliding in moving traffic flows. The book is replete with examples from experimental economics, but this section relies more on naturally occurring experiments such as pedestrians optimizing the pavement flow or the extent of crowding in popular restaurants. He examines how common understanding within a culture allows remarkably accurate judgments about specific reactions of other members of the culture.
·         Cooperation
How groups of people can form networks of trust without a central system controlling their behavior or directly enforcing their compliance. This section is especially pro free market.


Cheers!

Tuesday, January 22, 2013

Building a IT Service Catalog in 5 easy steps

This is a bit of a brain-dump of how to build the list.  The "5 easy steps" is a sarcastic protest against formula blog writing and the stupefying titles chosen for those posts. (thanks for tolerating my protest)

Begin a list.  Use excel, it does everything you need.
Write down all the services you know about, and then expect to stumble across many more services you haven't listed.  The list gets built iteratively which lets you avoid anxiety about it being incomplete.

For each service listed in define WHAT the service is.  Normally this involves a noun like "Network services".  Describe what the service provides in terms the requestors will understand.
List the verbs that apply to the service.  These are the common changes;
"Server - Backup", "Server - Restore", "Network - VLAN creation" etc.

Under each service, list what changes can be requested.  If the changes are valid but not request-able  mark those as "internal or technical" services.

I'm going to be vague on purpose and drift from "service to change".  If you have a tiny IT shop where BOB does everything this won't make sense, but if you support 30,000 users like we do where I work, then this will fit OK.

List who designs the service. There should be a group / department, and an actual person's name.  The name is the person you talk to if you need to ask that the service be modified to operate differently.

List who delivers the service changes.  Sometimes its the designer, often a group of IT foot soldiers who follow orders.  There should be a group / department, and an actual person's name.  The person named here is the one who gets complaints about how the service is delivered.

List what pre-requisites are necessary in order to request the change.
- Perhaps there are security approvals, or budget approvals required BEFORE requesting service.
- Don't get in the habit of holding requests for service in a holding pattern while the customer disappears to get pre-requisites.

List the minimum data set that the service delivery team requires in order to successfully deliver service.
- By way of example, in our organization, for Software, we need to know; Vendor, Title, Version/edition, PCname/device, cost centre number, requestor's department.

List the expected turnaround.  If your customer knows the service is normally delivered in 10 business days, this helps set the tone so they don't start "escalating" the next day.

Link to "Standard operating procedures" that have been developed to support consistent delivery of the changes related to the service.
Link to policies your requestors will need to follow / agree to; (electronic use policies/ password policies etc.)
Link to user documentation.
List "How to access the service" beginning with "Call the service desk at 604-555-1212".
Link to any request forms you have in place to support the service and related changes.
List eligibility information if you know it;  e.g. the marking software is available to instructors and teaching assistants but not students...

Enjoy!  I hope this helps.  If you want me to post a template that might be helpful, leave me a comment below.


Getting to ITIL - Where to start

When undertaking a quality program like implementing the ITIL (IT Infrastructure Library), it can be tempting to try to "do everything".  ITIL is particularly beguiling in this respect since pretty much everything it suggests is reasonable, important and such a gosh darn good idea.

I mean, we want to be able to manage incidents right? and to control changes, and to have a service desk, and to fulfill requests, and to manage capacity and to.... the list goes on.  On the one hand there are more problems to solve than staff to solve them (or hours in the day) on the other hand there are so many good opportunities, you basically can't lose, any improvement at all is useful.

The question is; "where to start?"

While I'm sure the answer depends on your individual situation, in my experience and from my conversations with other IT professionals, there seems to be a common pattern.

In a way it resembles medical triage.  Triage originated in World War I with French doctors treating the battlefield wounded at the aid stations behind the front.  They divided the wounded into 3 categories;

  • Those who are likely to live, regardless of what care they receive;
  • Those who are likely to die, regardless of what care they receive;
  • Those for whom immediate care might make a positive difference in outcome


In the same way, there are areas of ITSM where;

  • service will continue on without intervention;
  • service or circumstance is so broken that available resources cannot remedy the situation;
  • service can be significantly improved through intervention.

By applying triage as a model, effort is applied where it will do the greatest good.

PRO-TIP: Your IT staff are smart and usually see these areas of greatest opportunity.  Their pain. (sometimes cleverly disguised as complaints) will highlight items that need to be addressed (first).

In another way it resembles the discipline of fire-fighting.
Firefighting is a field that has gone from willing volunteers in ties and suits smoking cigars who showed up with their buckets to "bucket brigade practice", to an age where we have embedded fire-proofing in every building code and consequently every building in North America (and beyond).  The concrete firewalls, the sprinklers, the pull stations, the crash bars on exit doors, the exit signs, the fire marshalls, the extinguishers by the exit, the public annunciation systems.  By designing buildings so that they don't burn (easily) and by planning so that people can survive, we live in a totally different era, one where homes and businesses don't get lost to fire so regularly.

So, as with firefighting, in IT;
1. Put out the fires. Incident management provides response capabilities.  Without the ability to respond in a planned and appropriate way, IT organizations are so disrupted by unmanaged incidents that they can't function effectively.
2. Stop lighting new fires.  Change management is many things but in a nutshell it is about controlling the changes that are made to the infrastructure (and systems) in a production environment so that the randomness of uncontrolled changes don't disrupt service.
3. Plan fire prevention, Take stock of the existing fire hazards and make a list of the most pressing / dangerous ones.
4. Start fire proofing.  You have a plan. Work that plan.

PRO-TIP: Start light!  Nothing scares away talented staff more than making them follow a process that is too heavy.

Thanks for listening.  I wish you success as you make things better and improve the world :-)
Greg.