cazh1 » Change Management

Help for the Newly Minted Project Manager

Jim MacLennan — Tue, 22 Nov 2011 02:25:45 +0000

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?

Capture the benefits – what are we getting for this?

Identify total costs (hard and soft, let’s not forget the time we are spending in addition to our regular jobs)

Define success – how will we know we are done?

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

Change and the Crop Duster

Jim MacLennan — Sun, 25 Sep 2011 00:06:41 +0000

Drive south through the state of Indiana on I-65, and before you hit Indianapolis you will come across an impressively large array of wind turbines, the new vertical symbols of energy self-reliance and innovation. I remember not so long ago, when this section of the road was just miles of cornfields, as far as the eye could see. The tallest things out here were telephone poles and the occasional power line – but that was then, and this scene is now …

Click for the original ... (Chris Light at en.wikipedia)

Impressive, for sure, and the grid stretched to the horizon … Maybe every 50 yards or so, another flailing prop [of the] plain (sts). And then, as we passed a small airfield where a crop duster was coming in for a landing, I thought of the pilot’s new array of problems – and how truly shocking this change must have been.

Think of it; for years, crop dusters “owned the skies” – not just the soaring heights, but pretty much everything down to the treetops. What freedom they must have felt – seconds after takeoff, you have true aerial pwnership, with absolutely nothing in your way, all the way down to maybe 30-50 feet above deck.

360 degrees of freedom – literally – in the area that you need to operate, dropping whatever they are dusting with. This is a key point – it’s one thing to pursue an avocation (say, flying your private plane around each weekend on local hops), but when you need to really get down to business, relatively few of us have complete freedom to operate. Few fields remain (aiw) that allow performance of key tasks with whatever creativity and flair we might imagine.

But now, innovation and technological progress has introduced change, and a new reality sets in. There is more than one way to use the third dimension above their corn fields, and the farmers know it – they’ve implemented a private grid of wind turbines, generating power that cuts their costs, and an alternative source of income if they are able to sell back to the grid.

All good – except for our dashing crop duster. These interloping towers have fundamentally and completely changed the pilots’ universe, the rules of engagement, their degrees of freedoms. These windmills stand tall with flailing arms, right in the area where all the action takes place – the near-earth airspace above the corn, where planes must fly at treetop level to get their work done. The grid now defines the flight paths – zero degrees of freedom, your patterns fixed. Heck, I suppose one day they will have unmanned drones doing the dusting, humming through the skies like airborne Roombas, saving time and money- and taking a bit more magic out of life.

Can innovation ever be really lossless? Must we always lose a little in the transition to the future? Maybe – and yes, maybe the overall benefit really is there (else why would they invest all that capital!) – but change will always impact some in the population, and probably not 100% for the good. I’m clearly no Luddite, and there are multiple, obvious, and relevant benefits for most innovation projects. But don’t give short shrift to the cultural impact when implementing process and system change. Find ways to value the old ways, retain the science and maybe just a little of the magic.

Followup Notes: I originally wrote this note as a rambling thought exercise, taking a bit of poetic license without checking into the details. Turns out, a always, that the Whole Story is a bit more intricate …

This isn’t a wildly new observation – folks have been noting the potential impact of this change since 2009 (Can crop dusters and wind farms coexist?, from the Quad City Business Journal).
From another 2009 article (Windmills pose risk to crop dusters, from the Decatur Herald Review), a bit more detail on the dangers.
One solution to the problem, from the crop-dusters – charge farmer’s extra when wind towers come into play. Alas, that durn Law of Unintended Consequences – flyers are applying the surcharge when farmers’ fields are within 1.5 miles of turbines – even if there are no windmills directly on the property.

Ah, another instance where reality overcomplicates a poetic thought.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: Change Management, degrees of freedom, Field of Dreams, innovation, pwn, wind turbines, windmills

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

A Nice Knock-Down Argument

Jim MacLennan — Thu, 21 Apr 2011 02:47:50 +0000

Sales and the Gantt

“Why exactly does he want to meet again?”

I could sense the exasperation in Karl’s voice, faintly; the sales manager wasn’t about to slip out of his professional demeanor over some perceived technical triviality. But for the fact that the request was coming from his newly-hired PMI maven, he probably would have found a convenient excuse to skip the invite.

“I just don’t understand why we need this meeting … the projects are moving forward, we are meeting regulary, the team is communicating status – what am I missing?”

Karl had called me in to his office to help decipher these requests, and I was searching for the analogy that would let me get to my next meeting. “Ah”, I explained, “you are using the terms ‘project’, ‘tasks’, and ‘communicating’ … somewhat colloquially”. The familiar roll of the eyes – I am talking in high concepts, pausing as I speak, trying to compose precise prose on the fly – never a good idea. Karl is checking his vibrating iPhone and wondering if he can make his own next meeting – but we both know there is a nugget of truth here, just have to find the right words.

“Your PM is looking for detailed tasks and dependencies, right? Like a recipe for building a road, constructing a house – a repeatable set of instructions, honed over time, that produce a predictable result. That model doesn’t fit this project; it’s assumes full knowledge of the path to the end … but that doesn’t really apply with a consumer-facing project like this …”. A glimmer of recognition …

When I make a word do a lot of work like that, I always pay it extra

“It’s like asking you for a detailed task plan when you are negotiating the big contract – there is a general path, for sure, but your team always has to find the way to close by navigating the relationships and complexities. Could you write down the steps for a trainee to follow? Of course not – and that’s how your team runs its projects. Not right or wrong – just different.”

And then the lights came on. “Thank You!”, said Karl, “that’s what I needed to hear, simply put, I understand now. I can deal with this meeting now, I’m good .. gotta go ..”

Engineering, Excel, and Expectations

“Why is my machine freezing up? Don’t you know anything about IT?”

I must admit, the 3D-spinning rendition of the button assembly was the kind of flashy technology that people like to stuff a CV/portfolio with – but who am I kidding? I can hack file formats and automate PDF renditions, but debugging drawing layers and block interference in a 2M, 15-page technical drawing?

“Look, we install this stuff, but we can’t run it for you. I put Excel on the desktops of everyone in Finance, but I don’t write their spreadsheets for them.”

Deadline tension has a way of stressing the plasticity of common sense, and Mike’s expectations were a little out of true here. He actually laughed at that one – but the machine was still poking along, so he returned to the Task Manager and his Google searches, a tad less grumpy.

Executives and the Blank Slate

“There has to be an easier way”, said Sandra, the impatient executive.

Unfortunately there wasn’t; like most mature ERP implementations, earlier software didn’t quite cover the requirements list, and a bit of customization gets added here, here, and here. And, as entropy reliably applies to business process and code repositories, that stuff gets complicated after 10 years – hence our suggestion to reimplement the base ERP for this latest strategic acquisition.

“Why can’t you just tweak it?”

I’ve come to despise that word – co-opted from the hardware hacker’s lexicon, it has become a common term used by the non-technical to minimize and rationalize a patch, exception, and/or other workaround to deliver results with the minimum amount of near term effort. And, since IT is woefully unable to glibly quantity TCO, the tweaks persist.

But not in this case; since we had the opportunity [acquisition budget / slush fund] to reimplement [... if I knew then what I know now ...], the suggested approach was to create a new instance, model the business in a clean system, then “convert” the existing data into the new instance. Manageable, simple, some time involved – completely understood. However, our “tough customer” wanted to understand why we would do it that way, as opposed to “fixing” the application in place.

“You can start with a clean sheet of paper, or you can keep erasing over the old one”.

What a reaction – silent stare, then “Wow, that’s perfect – concise, complete – I get it!”. The mood lightened noticeably; Sandra couldn’t believe I had come up with that one one my own.

The Vendor Rep Brings Me Down to Earth

My own Blackberry buzzes, snapping me out of a self-satisfied smile. And my drinking partner for the evening snaps me back to reality, out of the reverie these old war stories had brought on.

“Yes, Jim, that’s how we are taught to close the sale. Make the solution relevant to the decision maker, using examples and analogies from their own experience – makes it easier to get over the objections”.

“Gee thanks”, I griped, “thought I had stumbled upon a secret recipe there.”

But then our conversation turned to the creative application of styles and approaches from one discipline to another; mash-ups in the change management world, as we passed the time until the rush hour subsides.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: abstraction, analogies, BlackBerry, business conversation, business savvy, CEO, creating understanding, elevator speech, euphemisms, Gantt, imagination, Project Management, project manager, short stories

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Design and Change Management

Jim MacLennan — Wed, 15 Sep 2010 01:49:11 +0000

Click for the original ...

I have developed a few strongly-held architectural beliefs, and one came up in conversation last week, during a spirited discussion on minimal quality requirements for a[ny] data mart. I hold that the data copied from source to destination must be provably correct and complete with little effort. When agile-ly rolling staged deliverables into production, I may not have all the attributes in place for full flexibility of drill down, but if you have [say] 1248 records in the source system, representing $154,238.54 of transactions, you better have exactly the same amounts in the reporting tool – easily checked with a simple hash total. There should be no inbound filters or transforms – save that stuff for the meta data and/or presentation layer.

How exactly does this relate to “design”?

I delight in obsessing over the details of layouts (screens, forms, & slides) and page formatting (specifically for the printed page) – possibly a bit too much, but it’s ultimately about user acceptance. If an application / report / presentation / document looks like it was thrown together, with extraneous messaging or ornamentation – well, people will use that as an excuse to write the piece off as complicated and/or incomplete. Often, when introducing new systems, tools, metrics, and/or processes, you are introducing significant change in people’s lives. There is always natural resistance to change – resistance that looks for anything to latch onto and call into question. Like rubbing a cotton ball over a rough surface – teeny imperfections will snag & fluff their attention, and distract from the view.

It’s much the same with my data mart example; these analytical wonders often expose uncomfortable truths or (more likely) opportunities that were there all along, just hidden from view. For the unbelievers, or those wishing to delay the [potentially] bad news, any excuse to question the validity and accuracy of the data will do. Do yourself a favor – a simple hash total proving that 100% of the data got from point A to point B helps limit the fingerpointing and focus debugging attention on a simpler set of scapegoats.

Change Manage the “Big Stuff”

Pay attention to the details of the design, how everything fits together – and obsess over the nits that will detract from the core message. This pays off big when nothing happens. Well, maybe nothing that you don’t want; communication with zero distractions lets you focus on the elephants in the room, where your change management energies will be best spent.

The design is successful when all the angsty conversation is about the new process you are introducing, the meaning behind the metrics – not the fact that the type is too small or the multiple fonts make something hard to read – or the numbers just don’t add up.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | One comment |
Post tags: agile, Art, Change Management, data architecture, data mart, data warehousing, debug, Design, details, elephant in the room, Execution, managing change, meta data, Mies van der Rohe, moose on the table, presentation layer, report presentation, usability, user interface

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Managing Change: Pick Something, and Do It Well

Jim MacLennan — Sun, 14 Feb 2010 23:08:00 +0000

This is the first in an series of posts on Managing Change … look for more over the course of the next few weeks …

A common way of expressing the holistic nature of a project is to talk about “People, Process, and Technology”. I’m not sure who came up with this little gem, or in what context, but I’ve been hearing it a lot lately. No particular reason, I think, just that it seems to be gaining a bit of status as a second-tier buzzword or something.

I’ve noticed, however, that people seem very comfortable talking about People, Process, and Technology in the As-Is or To-Be states – but precious little time is spent about the difficulties in getting Change to happen in any of these areas. Project teams and project leaders need to be effective at making Change happen with People, Process, and Technology; maintaining the status quo is comfortable, and envisioning the “nirvana” Future State is easy, but the real challenge comes in making the transition from A to B.

Click to enlarge ...

Project teams need people that have Change skills:

People Change – Soft skills and Emotional Intelligence are typically required, but effective team leaders need to be able to command a room of strong personalities and competing agendas. Some meeting facilitators are direct, and can shout folks down and/or eloquently shift the group’s understanding. Others work indirectly, creating understanding and acceptance in non-threatening, semi-private conversations.
Process Change – It’s easy to say “automate a mess, and you get an automated mess”, but the challenges of process redesign are known to many folks. A certain amount of patience and insight is required to ferret out muda (waste) in the process, to understand and identify the critical elements / tasks, and to aggressively involve the eventual process owners, cementing their commitment for implementation by making them part of the design.
Technology Change – Typically the easiest (and preferred) work area for IT folks, but for those who want to make a difference in IT, it takes the ability to understand and implement new technologies quickly, in a sustainable and supportable fashion. Points are taken off for quickly implementing a fragile system.

WIIFM?

Looking for ways to create concrete objectives for yourself or your teams? The significant Value Add that projects and project teams bring to organizations covers all three areas – People Change, Process Change, and Technology Change. Improvement and effectiveness doesn’t come from raw skills in People, Process, or Technology, but a demonstrated ability to make Change happen in any and all of these three areas.

The opportunity, of course, is to pick one or two of these areas, and build your skills in making Change happen. If you aren’t good in front of a group of people, and are more comfortable working directly with the technology, work on your Change skills by understanding new developments and methods, and figuring out how to use that stuff to make projects and processes happen faster, with higher quality and more predictable outcomes. Looking for a stretch? Get into Process design and development; it’s not always about the bits and bytes, but systems thinking is a big plus, and Process skills are often a great way to bridge from Technology to People skills.

Do you express your value to your team, and your value to the company, in terms of People, Process, and Technology skills? If you want to be successful in IT, work on demonstrating your value by making change happen in those areas. At the very least – be able to articulate how you have succeeded / can be effective at making Change happen.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | 2 comments |
Post tags: Change Management, creating understanding, emotional intelligence, innovation, Inspiration, knowledge transfer, leadership, managing change, People Management, process redesign, Tech Management, technical communication

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

What’s the Difference between Announcements, Blogs, Discussions, Wikis?

Jim MacLennan — Wed, 27 Jun 2007 03:50:00 +0000

Alternate Title: Battling Collaboration Memes

As mentioned previously, we are trying out SharePoint where I work, and I’m finding it interesting, maintaing 3+ blogs, including this one. Actually, the focus of the internal stuff is quite different, as Dennis McDonald and others have been noting. Lot’s of details and stories to write about, but one key learning we’ve captured recently …

With the SharePoint toolset, we can set up Announcements, Blogs, Discussion Forums (Fora?), and Wikis – sometimes all on the same site! If you think a bit, there’s can be very little difference between the entries on each of these lists. So, why the apparent repetition? What is the difference?

It depends on the type of collaboration you are trying to initiate …

Use an Announcements to make a statement, inform of an event, where you expect no comments or replies. The flow of information is in one direction only – out from you to the readers of the web page.
Use a Blog to make an observation, deliver a status update – capture a well-formed thought. One or two folks may have question or want to add a follow up, but in general you expect a few comments at most.
Use a Discussion Forum when you are asking a question, making a proposal, or establishing a new standard. Here, we expect a lot of discourse with threaded conversations and branches and such.
Use a Wiki when you are making a statement / documenting a fact. You should expect refinements, additions, and other edits – but not full-on discussions.

In fact – if you find a section in your Wiki is getting a lot of edits, questions, issues – try moving the topic to a Discussion Forum until things get worked out …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2007. | Permalink | One comment |
Post tags: Blog, Collaboration, discussion forum, SharePoint, Wiki

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Finding shapes in the fog – How to frame a wispy, wandering conversation

Jim MacLennan — Thu, 08 Sep 2005 03:10:00 +0000

An excellent discussion this afternoon, on a fairly complex topic we’re trying to move forward. When dealing with broad system concepts that have been trivialized into TLAs – think CRM, PLM, BPM, TQM, yada – you need to help folks define some sort of framework to focus and steer the initiative in a general (hopefully correct) direction. Precision is not required in the early stages – like herding cats, we can start making progress when we can capture a generalized, high level, but definite statement of the “end game”.

What does success look like?
How do we know we are done?

A typical early conversation about the Big Idea needs to define the Ultimate Objective. Expect to hear two mindsets weigh in; Tradition will muse on the challenge of changing The Way Things Are, while Innovation points out small, directionally promising successes that have led to this Big Idea. Be careful; there is always a sense that We could blow Big Bucks & Time on unfocused projects (not a good outcome), so a nice starting point is to laser in on our Ultimate Objective.

Look for patterns in the discussion; this afternoon, I saw a focus on

Driving (a change) vs. Monitoring (the as-is) [think Active vs. Passive]
Focus on Strategy (why) vs Tactics (how)

So, one way to attack this would be to build a mini-matrix, plus sample statements … for example, how might we prioritize IT requests?

(Drive Strategy) Enable forward-looking discussions about options (where to invest, dedicate resources, etc.)
(Drive Tactics) Facilitate “nimble” resource allocation decisions
(Monitor Strategy) Quantify project cost / benefit / risk
(Monitor Tactics) Drive productivity, ability to measure focus and results

You’ll need to refine and rework the statements based on some conversation, to fit the Big Idea. And these are admittedly high-level, vague statements – but they give enough focus to at least know where conversations should / should not go.

NB: This line of directed thinking is very much in line with classic scenario planning – I’ve gone through this exercise before on a grander scale, it generates some interesting insights.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | No comment |
Post tags: acronyms, buzzwords, idea, project prioritization, scenario planning, strategy, tactics, TLAs

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Subtle Anarchy

Jim MacLennan — Tue, 23 Aug 2005 02:42:00 +0000

In any organization – if you’ve been there for a while or are brand new – there aren’t many ways you can get away with introducing some change, shaking things up a little, and get away with it. Here are some stealthy, subtle ways to bring in a little healthy anarchy (they get progressively riskier) …

For recurring meetings, make a point of sitting in a different chair every time. People like to maintain the status quo, which often manifests itself by sitting in the same chair every time. Watch – notice how people always pick the same seat in those weekly status meetings? So … just arrive a little early next time, and sit in a new chair, one that someone else always sits in. Hilarity ensures as people come in, see their favorite chair occupied, but are too polite to say something about an ostensibly minor thing …
Another funny during meetings – if your neighbor is rocking their chair, you start rocking yours to a slightly different cadence. Try to be unobtrusive – this works great when they are engaged in the meeting and paying attention … they will subconsciously sense the difference and change their own rhythm to match yours. Fascinating …
Corporate templates for Power Points – make some tweaks and personalize these to fit your style. Now, this one is dangerous, because “good looking” “effective” “elegant” design elements are fairly subjective, and you should be pretty darn confident and correct in your changes, or this will backfire (ie. don’t make it look worse)! Also, you have to be fairly subtle .. don’t change the whole color scheme, or switch fonts from serif to sans serif. A typical corporate mistake is a too-big logo in the corner – try reducing the size by 10-15%, and re-positioning it.
Blackberries and iPaqs and most any PDAs come complete with time-wasting games. If I am really feeling on-the-ball, or I’m monitoring a meeting but not super-critical path or a key contributor, I have been known to play games. It sounds insane, I know, but I found that it actually helps me concentrate, because my mind does not wander as I listen to other folks talk. Let’s face it – it can be difficult to concentrate 100% on what everyone else is talking about – sometimes you are sitting there not listening, but waiting for your turn to speak. When fiddling with the PDA, any spare brain activity is taken up with a mindless breakout game, and I actually pay better attention than if I allow my brain to start working on other problems.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | No comment |
Post tags: meetings, MS PowerPoint, Presentations, templates

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

My Favorite Paradox

Jim MacLennan — Sat, 13 Aug 2005 17:20:00 +0000

Entropy (again), the great oxymoron/paradox of our universe … constant change.

I like the concept because it’s simple yet confusing, short/terse, and powerful (actively, passively, and conceptually). I think I picked this up from my Thermodynamics professor – an anti-Hesburgh Hindu at Notre Dame (love those tight loops).

There is a link to my current adventure here; I’ve noticed that when one is new to a situation / project / organization, there is a fleeting wish for “retroactive impact”. One’s mind drifts (during the orientation and getting-up-to-speed phase) to thoughts like wow, if only I was here a few years ago, when they made that decision, it could be So Different Now …

Relax – that’s what everyone thinks, that’s what I always think in a new gig. Patience … in a few years, you’ll have had the opportunity to take part in a number of design decisions, and make your fair share of Change … and if you implement poorly and/or don’t document, the next poor Sap will inevitably feel the same way … (Constant).

There is a flip side to this – and it’s key for change agents to realize. Those “problems” that many folks feel are chronic? Take this opportunity to look at them with fresh eyes, with an open mind towards tried and new ideas / solutions / options.

A related topic – excellent post this week at things magazine about Rephotography – comparing before and after pictures (particularly cityscapes), especially when the before is far in the past. Those two samples came from Canada (awesome site, BTW), here’s a collection from New York, and a nice site/project by Atget. This stuff makes you appreciate the history of places and things; neat stuff, helpful in staying grounded re: what’s relevant and important (constant) while the surroundings change.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | No comment |
Post tags: Change Management, entropy, paradox

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

First week, new gig – drinking from the firehose

Jim MacLennan — Sat, 06 Aug 2005 23:45:00 +0000

By the end of the week, “drinking from a firehose” became my massively overused one-liner to describe how the week was going. Still, nothing that was unexpected; new organization philosophies and theories, new terminology for familiar concepts, new “rules of engagement” for working with the technology infrastructure. Also, against my better intentions, it’s been tough to keep up with my postings, but I believe that will come in time, together with a different viewpoint on the stuff I write about.

Collected thoughts from the week, from meetings but also re: tie-ins from the blogosphere …

I knew before that I heavily depend on technology tools and tricks to keep track of the many things I am responsible for, but going through an environment / job switch really points out how flexible these processes have become (and must remain). I only have a reasonable amount of rework to do, I don’t design these things with a specific company in mind – this is actually the fourth generation for some of my older tools.
This post by Rothman (nice series going on there, also check out here and here) about the myth of competent talkers; in a related “talker” item, I remembered a sound bite from earlier this week, something like “… in a conversation, do you wait to speak, or listen and respond?“. Per Rothman’s post, if someone is not making a clear point, invest the time in listening, instead of waiting to correct them or make your counter point – something I like to remind myself from time to time.
I’m psyched at the opportunities / real business needs I am seeing for collaboration. A lot of the basics are there (or close), and it’s postings like this that tee it up nicely (although, when I saw the headline, I thought I was going to get something about AJAX and the new development paradigms … that’s a whole ‘nother kettle of fish … how fun to be disruptive …).
Related … an area where I will be expected to contribute some ideas and IT help will be R&D and product engineering. I have been exposed to some of this stuff IAPL, and some of the ideas expressed here (quite well) are going to surface, I’m afraid – the seemingly natural reticence of engineers to capture information in a sharable medium. Free exchange of ideas is often encouraged, and I think it does happen, but is verbal or at least not easily shared. I know that technology per se does not make change happen in these areas, but I still think that there is the opportunity to build a community with the selective use of technology, process, rewards, and encouragement.
I noticed that people speak quietly in the halls … I wonder how many people I will annoy …
No, I didn’t get anything close to this.
Saw some examples of the Shocked by Complexity meme; nothing truly new, I’ve seen this at every organization I’ve worked with, and at times, despite my best efforts, have been guilty of creating same. Everyone likes the one-page description of the complex topic, as if one page = simple. It’s a bit of an art to abstract to just the right level, to capture the idea/vision without going into too much detail. Unless, of course, you are working with / designing a reference guide (and if so, get over the shock, it’s just a learning curve).
This is cool. This is just funny.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | No comment |
Post tags: complex, engineering, euphemisms, listening, R&D, sound bite, terminology

All articles, blog entries, and other content on this site are licensed under a Creative Commons License