Go-Live Day

Congratulations! Due to the recent [acquisition / divestiture, market expansion / contraction, organizational realignments, other] you have been identified as a Critical Resource for this particular bit of business process change. And, to help us implement these changes, you have been named the Project Manager for this effort.

So now you are a Project Manager (PM, for short); what does that mean?

You may be vaguely aware that people get certifications for this sort of thing, or that Microsoft sells some Fairly Expensive Yet Sophisticated Software that helps create Can’t charts (or something like that).

You may also have this slowly growing sense of unease, as it becomes apparent that Project work is something that many folks don’t like to do – because being part of a Project Team represents an interruption to their already fully scheduled lives, with Tasks that will [by definition] someday End (… and where will that leave me?)

Don’t Panic

Every day, people in Operational areas of their companies get appointed to be “project lead” or project manager, but have had little training in formal Project Management. More often than not, however, the Project in question is of reasonable size (maybe 2-3 months in duration, with < 10 people on the team, and goals and objectives that are achievable “with stretch” (’cause if it was a no-brainer, we wouldn’t need to name you Project Manager, n’est-ce pas?). So relax for a bit, and let’s go through a little “crash course” in some of the basics of Project Management.

You may note, by the way, that much of PM may seem like simple ideas and common sense; this is true, and that’s a good thing to note – you’re calming down already.

Over time, you will learn that these simple ideas can be decomposed in many intricate bits; I wasn’t kidding about all that Certification stuff – as projects add people, systems, time and budget constraints, and shifting requirements, and you will understand why people talk about training and skills and battle scars …

Sorry, didn’t mean to lapse into that same old line of intimidating line of thinking … let’s just start with the basics.

What are we working on, and why are we working on it?

The new PM can be surprisingly effective with some fairly basic bits of information – clarity and reasonable precision go a long way when guiding a new team through a set of tasks that they aren’t used to doing every single day.

• Clearly state the objectives of the project – what are we trying to accomplish?
• What are the specific requirements? What are we building / implementing to deliver the objectives?

• Are there a specific set of features, functions, documents, new skills, new services, process addition/changes, etc. that need to be delivered?
• Any expectation of quality? Can this be slap-dashed together or must it meet the building code?
• Any time constraints? Is there any sort of must-have-by date, or can it slip a little bit (to get more features or better quality?

Note that Objectives are different than Requirements. I am trying to “deliver better customer service by delivering more accurate information on the invoice” (my objective). I will do that by “adding information to the customer orders, and printing it on the hard-copy invoices” (my requirements).

How are we going to get this done?

This is the most important, yet most often overlooked bit of PM work – you need to lay out the steps that need to get done, and who will do the work. Be careful – this is where many newly minted PMs get lost in the minutiae or intimidated by the details and intricacies – and folks often make mistakes in two different directions …

• Too much detail – bad, because the PM overhead becomes daunting, or the project work suffers from analysis paralysis and never gets started
• Too little detail – bad, because team members don’t fully understand dependencies, skip over key requirements, or underestimate work time

Keep it simple to start – you don’t need any fancy software or tools – a simple notepad will do. Just lay out the tasks required to get the work done, in sufficient detail such that you can reasonably gauge the total time required, and see where each of the major requirements will get covered.

You will also want to identify resources – people – who will do the actual work. Don’t talk in terms of “roles” or any fancy euphemisms – put actual names against each and every task. In addition, you’ll need to estimate how much time it will take to get each tasks done – you’ll have to add it all up, to check that it can all get done by any date you may have targeted for completion (ok, so maybe a spreadsheet would be a better tool than a simple notepad …)

Should we be working on this at all?

After laying out the tasks, you may find yourself going back to the total costs and/or the original estimated schedule with updates – and don’t be surprised if the time and costs increase, most people seem to estimate projects optimistically in the early stages. However, as your understanding of the total cost to deliver these requirements improves, it’s always fair to go back and validate if you should be working on this project in the first place – does it still make sense to go after the stated benefits if I know it will cost this much now?

The Most Important Thing

By far, the most critical responsibility for the PM is communication – you’ll want to plan and execute all of your project updates and track all project information as comprehensively as possible.

• Keep participants and sponsors aware of status – progress updates, major issues, coming milestones, etc.
• Track “planned work” (tasks) and “unplanned work” (issues)
• Capture knowledge – about new processes, assumptions, technical details, etc.

Remember, Rule Number One for project managers is Manage Expectations; most executives will tell you that they can handle disappointments when given enough lead time, but last-minute surprises are Bad, but magnified to Horrible with the lens of No Lead time To react.

A Nice Start – Now What?

Yes, you are right, there is much more detail to drill into on the Art and Science of Project Management. But let’s not forget that projects have been going on at your company for years – let’s not reinvent any wheels here …

• Does your organization have any standards or precedents in the functional area that you are working in?
• Is there a formal / informal, or traditional project methodology?
• Are there any existing communication requirements / expectations / traditions?
• Any available collaboration spaces, like SharePoint?
• Any available tools – for PM, for Training, for Knowedge Capture?
• Any available templates – for standardization, but also for short-cutting your work?

And remember, everyone else is happy they didn’t get picked to be Project Manager, so you don’t have to worry about competition …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: benefit, budget, business benefits, cost, critical resource, Gantt, managing change, managing expectations, managing projects, MS Project, MS SharePoint, project charter, Project Management, project manager, project planning, Requirements

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/help-for-the-newly-minted-project-manager/feed/ 1 http://www.cazh1.com/introducing-collaboration-tools-three-required-personas-for-success/ http://www.cazh1.com/introducing-collaboration-tools-three-required-personas-for-success/#comments Fri, 18 Nov 2011 03:25:36 +0000 Jim MacLennan http://www.cazh1.com/?p=1559

An early SharePoint cert test

When introducing collaboration tools to an organization – creating the corporate intranet, defining project sites in Sharepoint, etc. – there are multiple skills you must master – well, at least get better at. You need to capture the ideas and communicate the data such that your target reader understands what you are trying to convey – but you also have to help them locate it in the first place.

Three personas you’ll need to adopt, three sets of skills to master, if you want your stuff to be relevant and get read …

Librarian – Where to start with a big pile of information that needs to be captured and categorized? Consider the typical technical tome – when browsing at the bookstore, how do you pick the one you will buy? I will select the winner by browsing the table of contents, to see how the subject matter lays out – very important stuff. But how do you end up using it? More often than not, I keep going back to the index, to locate a specific word (topic) and find out where the author has stashed the details. The Librarian should know the vocabulary in the book and the surrounding / related areas of knowledge, and fill the index with the key words and phrases that folks keep coming to the information desk to ask about. Sure, most word processors will automate the pagination tasks, but there is some skill and art in choosing the right words – and making sure the document contains those words in all the right places.

Experienced authors who rely on the index to function as their “local Google” will go back to the text and place key words in all the right places. Savvy intranet content producers will anticipate the searcher’s keywords and make sure they are in the document and/or the metadata.

Marketer – There’s more to it then just anticipating the reader’s needs. It’s not enough to write effective prose – you need to create content that wants to be found. Attack the problem like an SEO expert; learn how the search engine indexes content, and what data and metadata gets scanned. The Marketer will understand the local lingo and style of describing things, and make sure to include those words and that style in the text. Be realistic and humble – the vast majority of the planet does not actually think exactly like you do. Think about how you search for stuff on the internet, but also work hard to observe and learn how other folks find and absorb new information.

Completing the document is not enough – success is only achieved when people are actually reading and understanding the material. And they have to find it before they can read it.

Coach – You can document and publish plenty of material, but unless you get folks to actually change their behavior and use the tools, it will sit their like those big fat binders from long-past meetings, lovingly put together for the big event but now gathering dust on the bookshelf in the corner. The key is to find the opinion leaders, the folks who set the standards for the group – and give them extra attention and detailed, task-oriented coaching to change their behavior. Target the experienced hand, the one that folks like to emulate, possibly the one who can dictate the team’s behavior – and get right on the keyboard with them, helping them learn how to use this stuff.

This approach clearly will not scale to a large, geographically dispersed team; but if you can Coach the team leader(s) – teach the right skills and set the right expectations – the rest will follow.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: coach, Collaboration, collaboration environments, collaboration tools, Documentation, empathy, full text search, Google, intranet, Knowledge Management, librarian, marketer, SharePoint, table of contents, taxonomy, team leader, teams, workgroup

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/introducing-collaboration-tools-three-required-personas-for-success/feed/ 1 http://www.cazh1.com/how-to-draw-an-owl/ http://www.cazh1.com/how-to-draw-an-owl/#comments Wed, 16 Nov 2011 03:27:41 +0000 Jim MacLennan http://www.cazh1.com/?p=1552 On Documentation

One recent afternoon I found myself in deep conversation with potential consulting partners, holding out for a difficult requirement: “Excellent Documentation”. That’s a tough one to quantify, let alone describe; why hold out for something at once critical and ineffable? Doesn’t every project talk about the importance of providing documentation, yet rarely deliver it? Don’t most people flip past the pages of detailed work process, going right to the keyboard to bang away, expecting tool tips and intuitive UI to guide them through? Aren’t most technical teams passive-aggressive on documentation, procrastinating until the final week, throwing something together that the project manager probably doesn’t have time to read and review?

Click on the picture to check it out in book form ...

Still, I will press on candidate firms that want to code/configure for me, to put their manual where there mouth is, and show samples of the documentation that truly allows me to become self-sufficient. Many will piously claim an ultimate goal; to walk away from the project and customer [me], leaving me fully trained and self-supporting – even though [he cynically observes] they are incented to maximize billable hours. (Yes, I know the real truth; consultants enjoy the “fun stuff” – coding from scratch / developing new. Maintenance, extensions, and bug fixing gets boring.)

Of course, the more thoughtful Business Development folks, having been through similar conceptual wringers, will point out the difficulty of quantifying “acceptable”. But it’s not difficult to visualize; like certain non-fiction books, the really well-written ones where structure and prose come together in a perfectly natural way. “It’s like God wrote that”, I like to say, “it couldn’t have been written any other way.” Sort of like the Potter Stewart Pornography Test – “you know it when you see it”.

On Books

This turned the conversation towards books in general – fiction or non-fiction, read for enjoyment only, without regard to platform (paper or plastic). In fact, this is a terrific interview question I like to spring on folks – What as the last good book you read? It’s interesting how often the technical folks respond with Kernighan and Ritchie or the Gang of Four (no no yes), but I really like to talk to folks who want to review the latest pulpy summer fiction, interesting history, or a real brain bender like Hofstadter or Kurzweil. This is a great way to get into how people really think – listen to someone get animated about arcane topics like how to measure things – really big things, conceptually impossible things. You can hear it in their voice, see it in their body language – and it’s this honesty and energy that you want working for you, on the project or the contract …

Back to the Documentation

… and that’s probably the best way to identify an excellent documentation writer – do they get excited and animated about the craft of good writing. Do they know it when they see it – and can they identify why it works for them?

In the end, I agree that this is my white whale, a recurring windmill against which I tilt. Why do people overcomplicate the pictures and the prose, and create confusion out of something straightforward? Is it lack of complete knowledge about the subject matter – or lack of ability to communicate complexity with simplicity?

No easy answers here, and we’re running out of our scheduled time. To help make my decision, I’ll ask for samples; I find the best way to request representative work is to ask for something that the candidate is “proud of”.

Epilogue

An excellent quote near the end of this conversation; “I don’t read manuals … I clunk, I’m a clunker … I Apple” [emphasis mine]. Fascinating how intuitive usability has made a verb out of a brand name and a design philosophy.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: analogies, Apple, communication style, creating understanding, Devil in the White City, Documentation, Hofstadter, Kernighan, Kurzweil, process documentation, Ritchie

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/how-to-draw-an-owl/feed/ 1 http://www.cazh1.com/fragmentation-of-social-sharing-environments/ http://www.cazh1.com/fragmentation-of-social-sharing-environments/#comments Sat, 22 Oct 2011 22:06:47 +0000 Jim MacLennan http://www.cazh1.com/?p=1473 Progress requires innovation, success spawns imitation, competition requires differentiation – and after 7+ years of “Web 2.0”, there are multiple sharing environments vying for our attention (and participation).

Content Creation

Blogging has morphed beyond it’s “personal diary” origins; Blogger, WordPress, and the various CMS platforms have moved to become a long-format publishing platforms that continue to evolve. My own experience with this blog (cazh1) and internal blogs at work has shown that “posts” are more essays, articles, documentation on what and how, status reports for projects or trips.

I’ve recently begin experimenting with a new (for me) type of blogging – I’ll call it short-format, and it hearkens back to the old-school, diarist model. This is a place to put short notes, observations, maybe sketches / photos for an Artist / Designer, code snips for a Engineer / Developer, or experimental prose for an Author / Poet. The format is exemplified by tumblr, a fast-growing platform that hosts some amazing content and is giving the old stalwarts some competition.

Click for the original ...

Content Sharing

But what about the Usual Suspects – Facebook and Google+? I don’t see these platforms as content creation engines as much as they are content sharing engines; ubiquitous Share This! links, the +1’s and Like buttons that give “social media” their differentiating characteristic; networks of contacts that are of a like mind, in your Circles or Smart Lists, add value and context to the original content.

I see Flickr and YouTube as hybrids. Flickr is driven by people adding pictures; you can see / browse / search, and it has a personal, sharing-my-photo-album quality. YouTube, in the other hand, is more like a new video broadcast network; lately, it seems like the number of personal videos is dwarfed by ad campaigns, political  messages, and music / entertainment videos.

Antics with Semantics

Yes, I understand that you can Follow other tumblrs. Facebook pages and Google+ circles are creating content as profound and banal as the bloggers. And I’m glossing over professional networks like LinkedIn, which can be oversimplified as an electronic form of career networking. All of this has great value, is very relevant to the conversation – but all have subtle nuances, different use cases where they drive value.

Where does Twitter fit in? The best description to date seems to be micro-blogging; the 140-character limit forces a style and controls depth of meaning – Twitter is more of a broadcast medium, a virtual bulletin board or cocktail party, best understood by watching trending topics when events are breaking. Content is created, and RT’s and hash tags give weight to an ideas current mindshare.

An Excuse for Experimentation

Clearly, there is no one best answer when trying to figure out how social networks can drive a business. There are many platforms and technologies, all of which are evolving to deliver different messages and produce different results. There is no one best solution – and the only way to be able to glibly comment on how this might impact your business is by diving in, learning what these things can and cannot deliver. Or find someone who had done it, who is still doing it.

Just don’t go by what you read in airline magazines or see on TV – sound bites won’t cut it.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: Blog, Blogger, business value, Facebook, Google, Google Plus, LinkedIn, networking, Social Media, Social Networks, Tumblr, Twitter, Web 2.0, WordPress, YouTube

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/fragmentation-of-social-sharing-environments/feed/ 0 http://www.cazh1.com/idle-time-is-a-good-thing-for-it/ http://www.cazh1.com/idle-time-is-a-good-thing-for-it/#comments Mon, 21 Mar 2011 01:28:22 +0000 Jim MacLennan http://www.cazh1.com/?p=1281

... given the right circumstances ...

Lots of good conversations recently about managing IT, Finance, and other constrained resources for projects. We have implemented tools to model available time; when trying to understand what new work can get added to the pile, it helps immeasurably when you understand how much time you have available, plus what else has been committed.

This has become a powerful process for managing chronically constrained resources – but one side effect is that other folks on the team can find themselves less-than-fully-committed. Note that I don’t say available or loaded with free time – most will readily agree that there is always something to work on. The trick is finding the right thing to work on.

I am reminded of something I read about in Goldratt’s The Goal; among other things, it observes that when optimizing a production line, it’s entirely probable that we will be underutilizing one or more workstations. If we optimize every workstation (point optimization), we will be building up inventory, and generating waste. For people on our IT team, “building inventory” means working on stuff that is of low priority, or creating new projects or tasks that are on someone else’s To-Do list – things that they just can’t get to.

These folks must go on idle – they have some free time! Unfortunately, it’s very hard for most people to allow themselves to actually be idle, or even appear underutilized (… if I’m not working like crazy, they’ll think I’m not adding value …).

Of course, time is precious, and you don’t really want to be burning idle time. This “common sense” approach has a name – Productive Use of Free Time, or PUFT – and for enlightened IT teams, it’s an excellent opportunity to invest in themselves and their processes:

• investing time learning new technologies (self-directed study)
• structured cross-training to understand other technologies, especially for those areas that are constrained
• root-cause analysis to stomp out nagging bugs
• process automation to make those repetitive tasks a tad less monotonous
• process documentation to capture and transfer knowledge, and make systems & processes easier to support

Caveat: Work generated to fill in this time can sometimes become a “priority” for folks, who feel they simply must finish things before they can get back to their high-priority project work. I think that some people just don’t like to leave things undone, work-in-process to come back to them later. This PUFT approach adds real value when you can leave things undone for a bit, and pick them up when you have time – it also teaches you to document things as you go, so you can effectively pick things back up again.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: cross training, free time, Goldratt, point optimization, process documentation, resource management, resource optimization, resource scheduling, Theory of Constraints

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/idle-time-is-a-good-thing-for-it/feed/ 0 http://www.cazh1.com/market-driven-data-quality-data-darwinism/ http://www.cazh1.com/market-driven-data-quality-data-darwinism/#comments Sun, 20 Feb 2011 01:15:46 +0000 Jim MacLennan http://www.cazh1.com/?p=1263 Just trying a little contrarian thought this week …

Have you ever noticed how much time and energy goes in to data validation? I think it stems from visual forms development and the wide variety of clever data entry controls that are available – everyone wants to write an app that gets the oooo, cool! vote of approval. But how much of that energy spills over from value-added to feature creep?

Regex complexity at its finest ...

When your IT peers are showing off their internally developed tools, or when internal departments put so much creativity into their departmental data collection apps, try stepping back for a moment and taking a look at the amount of development, documentation, training, and maintenance work that gets generated. These amazing, subtle, and visually compelling methods for gathering and validating data can become complex validation rules that try to guarantee that only pristine data is ever added to the list.

Is all of this really necessary? Is there real value-add to this approach? Often times the coding of validation rules is so complex that the code becomes fragile, and burdensome on future maintenance programmers. Another common problem – many specialized, departmental, and/or narrowly vertical applications have broad ranges of acceptable data – and the rules for permissible values need to be wildly flexible and adaptive.

But how about NOT validating the input? Why not let “market forces” take over?

I am talking about instances where people are trying to get data into a System That Makes Some Problem Visible – for example, a database of projects or technical resource requests that have to be prioritized, or financial data that has to successfully post into a centralized data collection / aggregation system.

It might be easier to just document the requirements for the data, and then let the best quality data survive …

For your Project / Resource Prioritization application, a project will not get added to the prioritization list until all the data is complete and correct. Even if it is complete, it helps to make the project description easy to understand, compelling, and business relevant – or else someone else will get the resources.

Your monthly data submission has to conform to these [data structure] rules. If it does not conform, it will be kicked out / flagged with errors. You are responsible for getting your data cleaned up and compliant with the specification, and your data submitted by [the deadline] – else your submission will be late.

Now, this does put pressure on us to document the data formats and requirements clearly – but this is probably faster and easier than creating a gallery of automated rule checkers to validate input. And, when the document is proven to be complete, correct, and sufficient (i.e. not too complex), it would make a pretty good spec for an automated data validation program.

Just a wacky idea – as system designers, we don’t have to control the world. Try making market forces work in your favor, just like content struggling for readership on the internet or new products looking for sales …

… may the cleanest data win!

thanks to ex-parrot for the regex from the illustration

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: corporate information systems, data management, internal development, maintenance, master data management, PMO, portfolio management, Requirements, software maintenance, software testing

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/market-driven-data-quality-data-darwinism/feed/ 1 http://www.cazh1.com/estimating-bird-dogging-time-for-project-tasks/ http://www.cazh1.com/estimating-bird-dogging-time-for-project-tasks/#comments Mon, 10 Jan 2011 01:18:41 +0000 Jim MacLennan http://www.cazh1.com/?p=1224

Click for the original ...

New year, new projects, and new adventures in getting folks to think in project management terms. I’ve written before about Calendar time vs. Effort time, but this past week we came up with a new distinction that is worthwhile to call out.

When working with the business and getting folks to estimate how much time it will take to complete a task, there are actually three different things that most people will talk about – and folks need to be clear on what we’re asking for:

Effort Time – The amount of actual working time it takes to get something done. This is typically a reasonably small number.

If I could work straight through, and get the answers I need from everyone involved, I would probably spend about 8 hours typing this report up …

Calendar Time – Of course, it is rare that folks from any business can work on project tasks uninterrupted. Typically, we’re planning 20-30% availability, so we know it will take about a week to get this task done – normal delays, time gaps really, that should be somewhat predictable.

… but I do have my ‘real job’, you know – I’ll get this to you by the end of the week …

No surprises to this point – but you must be clear when asking for time estimates during project planning. Are you going to go by Effort Time, and allow the resource availability settings tell you when you can expect a completion? Or are you asking for Calendar Time, and skipping the fancy stuff?

However – when getting calendar time estimates from folks, make sure you understand why something will take so long. Some folks, burned by past dependencies on recalcitrant contributors, will pad their estimates with Bird-Dogging Time …

… or maybe the week after – I have to chase down this information from a number of people.

Again, this is all quite natural and normal in most organizations; but you need to make sure everyone estimates and reports tasks and durations consistently.

It will take 1 month per system to set up a data feed with the customer? Are you kidding me here?

Calm down – that is most likely a Calendar time estimate, factoring in delays due to “negotiating” process and structure with the trading partner. Rest assured, plenty of other project work will be going on while the technical details get worked out. Just make sure folks understand your qualifiers, and that all tasks in the project plan are estimated somewhat consistently.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: calendar time, effort time, Gantt, MS Project, Project Management, project planning, time estimates

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/estimating-bird-dogging-time-for-project-tasks/feed/ 0 http://www.cazh1.com/sorting-with-sound/ http://www.cazh1.com/sorting-with-sound/#comments Tue, 24 Aug 2010 00:31:48 +0000 Jim MacLennan http://www.cazh1.com/?p=826 via Geek.com – yes, I subscribe to stuff like this in my RSS reader …

I thought this was interesting on two levels …

• The Engineering student within appreciates the differences in sorting techniques (although I think I could speed up that bubble sort …)
• I also think these videos provide a simple illustration of the power of multi-media information sharing; the audio helps the animated “description” of the sorting techniques

I freely admit to be a bubble-sort bigot, as I never truly understood the heapsort algorithm. But think how this combination visualization / audio tool helps illustrate the concept; I’d love to see an interactive tool that lets me step through the sort and see the loops and the “stack” of values.

Another important power of effective visualizations – they get your audience thinking in new and different ways as well!

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: algorithms, Art, coder, communicating complexity, elegant, interesting stuff, multi-media information sharing, programming, Science, sort, sound, stack, subtlety, technical communication, video, visualization, YouTube

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/sorting-with-sound/feed/ 0 http://www.cazh1.com/the-magic-in-the-middle/ http://www.cazh1.com/the-magic-in-the-middle/#comments Mon, 26 Jul 2010 02:58:49 +0000 Jim MacLennan http://www.cazh1.com/?p=612 I don’t know where I first heard that phrase, or what it originally meant, but I have been using it a lot in the last few weeks …

Consider the entire user population for any web site or application. You can generalize all user populations into three Pareto-inspired groups …

• Top 20% – The folks who “get it”, and have the brains, the interest, and the desire to fully understand the system / tool / report / whatever, and get the most benefit out of it. In Pareto terms, the 20% that get 80% of the value.
• Bottom 20% – The “hopeless”; those that just don’t get the concept (and need constant handholding), have no interest in using the app (at best, they will have someone do it for them), and no desire to expand their horizons and learn something new. In Pareto terms, the 20% that cause 80% of the problems.
• Middle 60% – aka “everybody else”. This is the group of users that could get value out of the project, process / program, but need more handholding, guided learning, and/or managerial promises (/threats) to commit to learning how to use and apply this new tool.

Click for the original ...

I call this last group “the magic in the middle”; this is the user group you need to win over to ensure success for the project. In corporate IT, most projects would be considered a failure if they only got 20% of their target audience to realize the promised value – then again, no one expects 100% success, especially with the bottom 20% of folks that will Just Never Get It. So, the make or break “target market” for training and retention is the “magic in the middle” – the folks who need a reasonable level of documentation and training to get things to work.

Note that “magic” refers to the fact that what really differentiates success – that core region of 60% – is the make-or-break group that takes the extra effort. It’s not good enough that your top finance folks understand the new reporting and analytics system – the middling folks that need more handholding and examples are the ones you need to focus on. It’s not good enough that your top project managers understand the new methodology – the journeyman PMs that have more tech background than change management and communication skills need guidance and templates and checklists to make sure the minimal I’s are dotted and T’s are crossed.

Interesting Observation …

This is one of the core reasons why analogies between corporate IT and consumer IT often fail. How many times have people in the business asked IT for projects as flexible, ubiquitous, user friendly, and high quality as Flickr, Basecamp, and gMail? Or tried to address internal communication and collaboration challenges with tools like Facebook, Twitter, and Google Groups? Why do folks look at highly target-marketed sites / communities of practice, and cynically wonder why internal IT can’t turn over project requests with the same level of speed and quality?

One key reason – those sites only need to go after the Top 5% group of focused, engaged, and technically able potential consumers – because the internet is so big, there is plenty of money to be made from such a small percentage of the total user population. Unfortunately for corporate IT, it is not OK to implement systems that are effective only for 20% of the target user community – expectations are more like 50-80% of the user population needs to be reasonably glib in the system to be judged effective.

… but What Does It Mean?

Corporate IT is forced to go after the “middle” group – the 60 percent of the user base who needs a lot more TLC to understand and be effective in the tools and systems we provide.

However, I call it “magic” for a reason. You can leverage a lot of value once you realize that “the magic is in the middle”:

• Training: When you understand the low-end expectations for end-user competence, you can target your training material at that level – and no lower.
• Testing for 100% of all cases is exhausting and time consuming, a real drain on resources. However, only testing the basics (the Top 20%) won’t require a lot of rigor, for the error checks are simplistic and the level of scrutiny is much higher. If you want to do an acceptable amount of decent quality testing, your test cases should involve “the magic in the middle”.
• Vendors: Bringing them in for a demo? Salesmen typically target business scenarios that are the “low hanging fruit” (in the Top 20%), and it’s easy to understand when the software can’t handle the “worst case scenario” (the Bottom 20%); get the sales team to demo something from “a typical Day In the Life” (the Middle 60%)

The Top 20% group is the easiest to service, the Bottom 20% is the easiest to ignore. The magic is in the middle, and success here separates the excellent from the also-rans in corporate IT.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: cognition, education, Facebook, Google, LinkedIn, Social Networks, Twitter

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/the-magic-in-the-middle/feed/ 0 http://www.cazh1.com/defining-business-benefits-hard-and-soft/ http://www.cazh1.com/defining-business-benefits-hard-and-soft/#comments Wed, 07 Jul 2010 03:09:27 +0000 Jim MacLennan http://www.cazh1.com/?p=593 All projects should have a clear objective, a practical plan,
and an understanding of the costs and benefits to get the thing done.

Easy to say, but a lot of project teams struggle to crisply and clearly define specific business benefits. One way to move the process forward would be to have a clear understanding of the types of business benefits you might claim.

Hard benefits come from firm commitments to make measurable differences in the amount of revenue generated or savings realized. When claiming hard benefits, the business manager will actually increase their revenue budget (or reduce their expense budget) because of the impact of this project.

• Real, measurable “Top Line”: volume / revenue growth
  • “I will be able to sell 10% more …”
  • “Market share will grow 2% …”
  • “This new product line will generate 5MM pounds incremental sales …”

• Real, measurable “Bottom Line”: cost reduction, FTE reduction (people)
  • “I will cut 10% of my use of electricity …”
  • “I will eliminate two FTEs [positions] …”

Your guess is as good as mine ...

Soft benefits come from the strong belief of the business manager that the benefits will be there – but they may be hesitant to make changes to their budget. The hesitation may be there because there is some risk of attaining the benefits from other factors; or, the savings are based on unsubstantiated estimates (i.e. “educated guesses”, aka onager heuristics). When claiming soft benefits, the business manager may not necessarily increase their revenue budget (or reduce their expense budget), hedging against other factors.

Productivity – Many systems projects involve automating manual processes and/or streamlining overly complex processes. Productivity is increased when it takes less time for fewer people to generate more work and more results.

Productivity benefits are quantified as a reduction in the total number of effort-hours per month required to perform a task. We often speak in terms of full time equivalents, or FTEs; to keep the math simple, one FTE is about 2000 hours of work per year.

Productivity is a soft benefit because we do not always remove people from the work force when implementing productivity improvements. Typically, the aim of any automation is to free people up to do other process management or analytical tasks. Note, however, that you can turn productivity into a hard benefit by reducing either overtime or headcount.

Note also that it is difficult to establish a common and fair hourly rate for a worker, due to many factors (including job type and geographical wage rates). For this reason, it is sufficient to express productivity in terms of labor hours saved.

Next: Marching down the P&L and the Balance Sheet

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: budget, business benefits, cost, cost avoidance, finance, Productivity, revenue budget, total cost of ownership

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/defining-business-benefits-hard-and-soft/feed/ 0