cazh1: on Business, Information, and Technology

Finally! Relevant Applications for YouTube and Twitter in the Enterprise!

2008-07-11T13:58:00.001-05:00

Finally! Relevant Applications for YouTube and Twitter in the Enterprise!

If you are involved with manufacturing these days, you've no doubt heard about Lean Manufacturing. I'll not go deep into this area here, but one fascinating (for me) aspect is the thread (in some quarters) that ERP and computer systems are the enemy of Lean. On the whole, I don't disagree - process improvement, kanbans, and attacking muda are typically very physical exercises; roaming the floor, walking through the processes (gemba walks), reorganizing workspaces for flow, designing and simplifying standard work - all very visual, participatory efforts that continue over time (constant improvement). Computer systems can just get in the way - metrics and measurements that require extra data entry, or inflexible processes that can't be changed quickly. Much of Lean thinking is common sense and practical, applied thought - computers can over-complicate things!

However, it's that visual, participatory nature of process improvement that can be something of an obstacle, especially if you're working in an extended organization with many locations. It's difficult to gain insight over the assembly process unless you're standing at the bench, twisting and turning to reach for components. It's hard to design practical speed improvements for changeovers if you aren't there handling the tools / molds. And it's often extremely difficult to get the folks who know how to do this stuff (operators) to effectively document their work!

Enter the YouTube idea (which I freely admit is not my own, but the originator has no problem sharing his insights). Travel budgets are shrinking, time away from the shop is tough - but all I need is a 5 minute show-and-tell of a process. Why not a quick video? It's hard to describe how I can easily, visually manage WIP until you stand in that one key spot on the floor, and see how the sight lines to the various workstations all line up perfectly. Why don't I just show you ...

What about Twitter? Well, eMails, blogs, and wikis are really just fancied-up documentation tools, and nobody likes to create documentation. But Twitter can be terse, instant, and informal - not too intimidating for the itinerant author. Heck, sending tweets about ideas and observations on the job would be very much like sending text messages from your cell phone, an increasingly common, popular, and non-threatening task. The bonus, however, is that Twitter traffic can be broadcast (unlike your typical point-to-point text) and saved to a database for further review and insight.

Now, the public YouTube and Twitter sites are probably not the way you want to implement these ideas; much of what we're Tube-ing and Tweet-ing is company confidential. Corporate IT should get involved - either host it yourselves or properly vet a third party site for access & availability, storage & security.

... finally, a chance to walk into the COO's office and say "tweet" with a straight face ...

Interested in more Lean Manufacturing resources? Here's the best of what I've found on the 'net ... check 'em out!

Previously ...

Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
Misapplying the Pareto principle (January 7, 2006)
Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
Defining an Effective IT Metrics Framework (January 21, 2007)
Defining the Business Value of a Project (October 25, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)

Technorati Tags: best practice, business value of IT, innovation, Knowledge Management, operations, supply chain, technology, twitter, Web 2.0, youtube,

Don't Accept Snap Answers Too Quickly

2008-07-06T21:53:00.003-05:00

Don't Accept Snap Answers Too Quickly

A few years ago, I was working on an interface project, and wanted to have the ERP system send copies of any and all transactions that have changed over the past few days. I've done this before on other platforms, so I asked the lead developer what I thought was a no-brainer request:

Do the transaction files capture a date/time stamp somewhere in the record, each time the record is modified - DateLastUpdated, something like that?

His answer came back almost immediately ... No. Well, I guess this is possible, but we're working with a fairly up-to-date ERP, and I've worked with enough systems and data bases to know that many/most applications timestamp their records when updating, or maybe write changes to a log file of some sort. And the answer came back just a tad too quickly ... so I asked the question again, but this time I took some time to preface my question with an apology (of sorts) ...

I mean no disrespect, I am fully aware of your experience and skill on this particular platform - but I need to be clear, because I think I'm asking for something that's fairly basic.
I just need you to be a tad more specific when you say 'the system doesn't do that'.
Is it more accurate to say 'I have never seen the system do that' or do you know for a fact that that the system cannot do that?

It's a subtle difference, but it's important to drill into this level of detail. Most of us are pushed for time and quick to come up with the fast answers, so we can move on to the next item in the todo list. Answering off the top of our head is a pretty normal response, I do it a lot myself, but this was a pretty important feature request because the lack of it meant a ton of additional work in other areas. Besides, I'm humble enough to know there are many features and functions in any platform I've ever worked on that I don't fully understand - never had the need. Plus, I don't see a ton of wildly original thought and unique features in many of these system that we work with. In cases like this, I'm asking for something that I've seen in another platform, assuming that the author of this platform was a reason intelligent person and has added that same basic functionality.

Truth be told - in this instance, the transaction file in question did not have a DateLastUpdated field, and we had to look at transaction logs to get the information we needed. Still, the developer in question had little problem with my pushback; he readily acknowledged that he did not have the layout of this particular table memorized, and had never heard of such functionality - but the concept made sense, and he was happy to look. Besides, if his snap answer was wrong, it would have saved him a ton of work ...

Drilling into the specifics like this (do you know No, or do you Not Know?) applies to more than just software developers. Engineers lawyers, accountants, sales reps - many folks from across the business are faced with questions that they try to answer from their Experience, hoping for the Quick Answer. It takes some confidence to question the "local expert" - but if the right questions saves a ton of effort, searching for a workaround - well, that's an excellent question to ask.

Previously ...

Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
Making the internal pitch? Learn from the entrepreneurs (October 10, 2005)
Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
Misapplying the Pareto principle (January 7, 2006)
Beware the Self Fulfillling Prophecy (May 23, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
War Stories from the Change Management front (August 21, 2006)
The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
Communication is the responsibility of ... (August 19, 2007)
Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Why are those Old Programmers so slow in picking up on the Intarweb? (April 6, 2008)
There ain't much IT in IT Management (May 7, 2008)

Technorati Tags: best practice, collaboration, design, development, hands on, people management, project management, tech management,

IT and the Business are Closer Than You Think

2008-06-28T15:37:00.001-05:00

IT and the Business are Closer Than You Think

A few passing observations from the last few months; contrary to what many (IT/business) folks believe, they are just as good or just as bad in managing processes and projects as their counterparts in (business/IT).

Problem Resolution is Everybody's Problem

A few weeks ago I was discussing issues that came up with one of our systems, and the team was a bit dismayed that the user community was still finding errors (we should be trapping for that stuff!) I pointed out that it's illogical to worry about stuff like this. We've implemented fault-tolerant systems that predict as many problem situations as we can think of, with lots of alerts and doublechecking built-in. If we can think of a problem, we will build a trap for it. It stands to reason, therefore, that the only bugs to appear are the ones that we couldn't anticipate - so the only people that will experience the bugs will be the people using the system.

It's inevitable that end users will find your problems, and that's nothing to be concerned about - we're all testers, and testing never really ends (in a continuous improvement environment). What you should be concerned about - how quickly we can turn around a fix for the problem? What is our total uptime? Do we see decreasing numbers of new problems, and zero recurrence of previously reported problems?

Truth be told, the onus of root cause is just as much on the business. Was this a scenario that could have been predicted? Were the requirements amd/or testing scenarios complete? (... apparently not ...) When projects are well run, and it's a true partnership between IT and the business, misses like these are everyone's problem.

Nature Abhors a Vacuum

Business managers may not understand the details of the technology they work with, but they certainly understand good management techniques. Try working with any manufacturing operations group and not going to them with metrics or KPIs (Key Performance Indicators). This is their bread and butter; they cannot understand how anyone could manage without some form of metrics. And if they see none, they will not only notice the problems, but will proactively look for issues, assuming things aren't under control.

On the other hand, if you have a reasonable set of metrics and are managing to them, they certainly can't accuse you of not following sound management principles. They may provide feedback that the quality of their experience is still not the greatest - but a structured, metrics-driven approach shifts the conversation to towards a discussion about best metrics to manage to, and not whether or not IT knows what they are doing.

In the End, We're All [Bad] Programmers

Check out this article from CFO.com, detailing a number of "worst practices" that folks in finance to see their counterparts doing that make them cringe. Sound familiar?

Poor Segregation of Data: Mixing critical values with complicated algorithms (business rules) makes for a delicate and hard-to-maintain spreadsheet (application).
Poor Documentation of Assumptions: when revisiting (cloning/debugging) this report, if you can't remember the original assumptions (design), you may need to rework (refactor) the entire thing
Poor Documentation of Constraints: complex worksheets with many simultaneous calculations would benefit from interim formulas in key cells (asserts) to test reasonable boundary conditions
Difficulties in Making Changes: spreadsheets and formulas can and should be structured to allow for foreseeable extensions and modifications (subroutines)
"Now It's Here; Now It's Not": at times it's too easy to change values in the worksheet to test different assumptions. And then lose track of all the changes made over time (version control)
The Presentation Readiness Problem: when creating spreadsheets, analysts (programmers) should anticipate their use in final presentations (user interface)

In summary, the author provides this sage admonition ...

Treat the development of a spreadsheet - any spreadsheet - more like writing a term paper with footnotes and a bibliography.

See that? Accountants and programmers should aspire to be ... students?

Previously ...

Heisenburg KM (July 13, 2004)
Does IT make you productive (or, are you an existentialist or a fatalist)? (February 26, 2005)
Things for the DIY programmer to consider (March 14, 2005)
Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
Sometimes analogies work amazingly well ... (July 14, 2005)
Of course we can pay for that ... if it makes business sense (November 7, 2005)
Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Stretching Your User Interface Design Muscles (April 16, 2008)
There ain't much IT in IT Management (May 7, 2008)

Technorati Tags: best practice, business value of IT, development, documentation, tech management

Data Visualization: 'Life' of Open Source Projects

2008-06-16T22:07:00.001-05:00

Data Visualization: 'Life' of Open Source Projects

Part of the "art" of communicating IT and business abstractions - technical challenges, project roadmaps, budget performance, customer relationships, IT effectiveness - is landing on the right visualization. A picture tells a thousand words, and if you can draw the picture well, your target audience will grasp these concepts quickly, and (potentially) get insights that were otherwise difficult to attain.

I have a large backlog of web links to point to, posts to write that I'll probably start cutting into, now that I've seen this latest bit of visualization ... via Slashdot ...

A student at UC Davis has created some stunning visualizations of open source software contributions, including Eclipse, Python, Apache httpd and Postgres. From the website: "This visualization, called code_swarm, shows the history of commits in a software project. A commit happens when a developer makes changes to the code or documents and transfers them into the central project repository. Both developers and files are represented as moving elements. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away. A histogram at the bottom keeps a reminder of what has come before."

As a developer, I can draw connections between the narration of significant events and the "flow" of objects. I've used these tools/platforms for some time now, and the story told by the animation connects nicely with my understanding of these tools' "personalities" - gives some insight on how they "grew up".

Python: This one fits my understanding of a typical open source project; lots of work by one primary, maybe one or two secondary developers, with fits and starts, bursts of activity. Over a period of time, a limited number of additional authors contribute, and things slowly expand until critical mass is hit, and Python is released to the public. Then, a flurry of activity as the popularity takes off ...

code_swarm - Python from Michael Ogawa on Vimeo.

Apache: I was fascinated to see this project start off as an exercise in documentation - and stay like that for the longest time (code doesn't appear until about a third of the way through the movie). Like Python, Apache is a focused platform/application, and had a fairly concentrated core of developers and modules - unlike ...

code_swarm - Apache from Michael Ogawa on Vimeo.

Eclipse: I watched this movie first, but it belongs last in the To-View list. Eclipse is a wide-ranging platform with a large number of modules/functions - and a correspondingly large number of developers. It's amazing to think that the overall project could maintain such a high-quality, unified vision.

code_swarm - Eclipse (short ver.) from Michael Ogawa on Vimeo.

I'd love to see the Linux video ...

Previously ...

Another Spam Graph - The Impact of Spammers Changing Tactics (September 17, 2004)
Communicating Complex Technical Concepts (March 21, 2005)
Spam Graph redux (nice filter!), and an interesting meme I stumbled upon (May 24, 2005)
Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
Build a Framework: Your chart junk is my roadmap / vision statement (December 27, 2005)
Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
Measuring and Reporting IT Value (1 of 2) (November 16, 2007)
Measuring and Reporting IT Value (2 of 2) (November 20, 2007)

Technorati Tags: design, innovation, presentations, technology, visualization

More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions)

2008-06-12T23:24:00.000-05:00

More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions)

A recent post got a surprising amount of feedback - at least, different feedback than my other stuff. No flames, just folks agreeing with the ideas and wanting to engage in more direct conversation (phone calls, as opposed to blog comments or email - interesting ...)

I've noted that people like to second-guess and/or heap scorn upon their executive management team, seeing them as disconnected, clueless, and capable of speed without forethought. However, my experience tells me these attitudes are way out of line. Spend time in one-on-one meetings with them; listen when they ask probing questions during staff meetings, operational reviews, or any other meeting where they're going over details and weighing in with opinions. You can develop a much better understanding of where they're coming from if you attempt to walk a mile in their shoes - or just empathize a little bit.

These are common misperceptions that a typical organization has of the executive team ...

They Don't Make Decisions ... they just keep asking me for my opinion when I need them to make the call! Actually they're doing two things correctly; managing their time (because they can't micromanage the whole company) and empowering the organization (ie. giving you 1> credit for having half a brain, and 2> some leeway to make decisions). Remember, most organizations need problem solvers, not problem definers.

They Don't Consider All the Angles ... they skim the details and focus only on the big picture. People often make decisions without considering all the options and all the details; it’s a time management technique, relying on intuition backed by experience. It's just a tactic to help manage time, get on to the next thing - so don't take it personally. A better approach would be to give them the overview, let them know your decision for the go-forward approach - and then ask for feedback. If they disagree with your fundamental approach, I guarantee they will not be shy - they'll let you know right away. If you don't want them to make snap decisions that have huge impact, reduce their snap decisions to minor fine-points, and guide them where you want. If you really know your business and your audience, the executive input should be fine-tuning, not fundamentals.

They Resist IT / Technology ... the dinosaurs just don't get it! Truth is, they are much more technical than you think. I've had executives call out IT baloney about SQL queries, application response time, even e-mail attachments (I was told this attachment was too big to open - but later I was driving down the freeway at 80 miles an hour reading it on my Blackberry!). They don't need to understand the technology in gory detail, and you don't have to educate them on the nitty gritty - but they certainly need to understand how a given technology decision impacts total cost to implement, quality of the deliverables, speed-to-value, and ongoing cost to maintain.

They Aren't Paying Attention Well, not exactly. They will ask you to cut the details and get to the punch line, typically because they're thinking on a completely different level. You're probably worried about your departmental budget, annual performance goals, and/or resource constraints that put work for the next few weeks in jeopardy. They are thinking about making the month, making the quarter, and managing the owner's/shareholders' expectations for the next quarter or fiscal year. Also, they've got review sessions with engineering, marketing, operations, and finance - all scheduled between now and the end of the day. So, forgive them if they're not up to date on the differences between IE 7 and Firefox.

They Don't Understand the Problem Domain Actually, they typically have a deeper / more nuanced understanding of the business than most. They know (intuitively and factually) how to impact key numbers on the financials, and what levers to pull when they want to make a noticeable change. Questions that seem out of left field are actually efforts to make a connection between "why should I invest in this project?", and "how does this tie to one of my levers?".

Recognize that the executive team comes at the business from a different angle, and learn to listen to what is important to them - you'll raise your project success rate, demonstrate your value to the company - and maybe chill out a bit.

Previously ...

Sell your Boss - Some Tech Observations (January 30, 2005)
Fractal Business Issues - Katamari Damacy at Work (February 25, 2005)
Communicating Complex Technical Concepts (March 21, 2005)
Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
Open Source as bargaining chip - driving business value of IT (October 30, 2005)
Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
Build a Framework: Your chart junk is my roadmap / vision statement (December 27, 2005)
The "Army Rangers" model for IT Professionals (January 2, 2006)
Misapplying the Pareto principle (January 7, 2006)
Defining an Effective IT Metrics Framework (January 21, 2007)
Communication is the responsibility of ... (August 19, 2007)
Defining the Business Value of a Project (October 25, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
There ain't much IT in IT Management (May 7, 2008)
Can you, should you, bother Executives with The Details? (May 30, 2008)

Technorati Tags: best practice, business value of IT, operations, PMO, presentations, tech management

Opportunistic Insights from the RSS Stream

2008-06-05T22:42:00.001-05:00

Opportunistic Insights from the RSS Stream

I've written about using RSS for internal as well as external information sources. This past week, I found a couple of interesting tidbits in my feed reader (behind the firewall) ...

1. Eyes on the Skies: It's that time of year again; oil price volatility will continue if any big storms create problems for refineries in the Gulf - something new to keep an eye on. Never fear - our friends at NOAA kindly put out an RSS feed for storm details - here's the latest graphic on Tropical Storm Arthur, the first of the season. You can keep track of incoming storms using this RSS feed - at the very least, you can be first on your block to know the name of the next storm ...

Some of the responses to this original item pointed out the need to watch the tornado forecast as well put and potential impact on manufacturing plants and/or shipping lanes. There are many different ways that weather can impact the supply chain ...

2. Innovations in Materials: Another item made some interesting predictions on future impact of bioplastics.

New applications in the automotive and electronics sectors will drive the growth, although packaging will remain the dominant market. This is despite its share forecast to fall from 65% in 2007 to 40% in 2025.

I took this to mean that packaging is the dominant application of bioplastics, and will remain so. However, the future will see multiple other applications for this material emerge. More applications means larger markets, more innovation in the basic material - which is better for all plastics manufacturers.

3. From Rumor to Fact: One of the project managers recently added (1234) Project XYZ to our PMO database - I found out when the items popped up in my feed reader. That's how it's supposed to work ... Actually, my first reaction to the project was that the description (jpm note: we call it a "mini_charter") was a bit thin. But then I read the first comment, and there's definitely more meat there. At this time, Project XYZ is a multi-headed mystery monster - there are initiatives, teams, projects and such in multiple areas of the company. Clearly, more details to follow - but now we have a validated source of information for at least one of the BU's!

Show vs. Tell

These were my insights for the week, but a number of folks have told me of their own Aha! moments, watching project updates aggregate on their desktop via RSS. I suspect most folks reading this would think little of my "insights" - but that's because we understand how RSS works. To the rest of the world, websites are proactive (I have to go to them) while e-mail inboxes are reactive (the information comes to me). RSS and feed readers turn that paradigm around; once you see it in action, you get it immediately. But it's enough of a phase shift that sometimes explanations and PowerPoints aren't enough. Timely, relevant, in-context examples such as these just click.

Previously ...

Tracking patent submissions via RSS (June 1, 2005)
Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
More on (sic) experience with wikis (January 31, 2007)
Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
Butting In to the Conversation: PM Communication Tools (February 26, 2008)
RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)

Technorati Tags: blog, collaboration, documentation, innovation, Knowledge Management, PMO, project management, RSS, Web 2.0, wiki

Can you, should you, bother Executives with The Details?

2008-05-30T20:43:00.001-05:00

Can you, should you, bother Executives with The Details?

In a recent post on Thinking Faster, Phillips expresses concern about the apparent propensity for project sponsors to skim over the details and jump to quick answers. He's talking about [what I believe is] a peer relationship, when external expertise is brought in to develop the solution that they (the sponsors) are responsible for "owning" (vision, design, execution, and ongoing support). I've seen the same sort of thing in multiple organizations, especially when talking with executives about projects and initiatives that they are championing. It's a slightly different scenario than described in Jeffery's post - reporting status "up the chain" versus "to the customer" - but multiple nuances of "don't bother me with the details" come into play just the same. My only suggestion to Jeffery would be to exercise a little empathy and adjust the message. Management needs to understand the details in spite of their objections or shortcuts; the trick is to understand what's behind this drive for the quick answer, and adjust the communication accordingly.

Fractal Attention Span

Challenge: People typically work on 7-10 major items at any one time; that's about as many as the brain can comfortably prioritize for chunks of their attention. Unfortunately, these to-do items / projects are fractal in nature, easily decomposed into multiple tasks and subtasks. Our prototype CEO needs to deliver increased revenue (3 key accounts in play), reduced costs (2 cost cutting and 3 productivity-enhancing initiatives), while driving down inventory (S&OP, SKU reduction, and supply network optimization projects). Oh yes, there is also a pending lawsuit, product R&D reviews, and the board presentation to develop. The VP of Sales has five territory managers working on different aspects of the three key accounts, and two project managers working on the cost-cutting - in addition to ongoing promotional planning and customer service issues. Sally, the lead project manager on the first cost-cutting project, is working towards a launch date of 15 July, and has 10 open issues with varying degrees of severity.

If I'm the CEO, and I have two hours to complete an Operations Review for the entire company, I have maybe five minutes to listen to Sally tell me about her piece of the VPs piece of one of my 10 hot items; do I really have time to hear about usability issues or the challenges of scheduling acceptance testing? All I really need to hear is the specific objective of the project, current status, maybe the next milestone date, and our current expectations for meeting the stated objective (vs. budget and/or need-by date). Anything else and my eyes will glaze over, because I've got 20 other people to get through, backlogs in voicemail and e-mail, two more meetings before the end of the day - and I'd like to get home before midnight.

Mitigation: This environment is hostile to knowledge retention (ie. you risk the CEO spacing out), so you need to focus on the critical information. I (the CEO) need to hear a clear objective, a plan to get there, and an active monitoring process. I don't care about the options available or the decision process for task 4.2.6.a on your plan - I just need to know you are planning the work and working the plan.

"I don't believe you" might mean "I don't understand you"

Challenge: Phillips' post captures his frustration when project sponsors ignore input on usability and data access. Features and functionality are stressed over the intended audience's capability and willingness to use what is being built. Experience in creating and implementating software-enabled processes teaches you the impact of a poorly laid out web page, but this is experience that your project sponsor doesn't have. They assume all software is built consistently (look at Microsoft Word and Excel!), and that Google, Amazon.com, and YouTube are "user-friendly" solely because they're on the web (web = friendly and easy, right?).

Regardless, your [sample] project sponsor is very aware of one fact; their integrated demand forecasting system, driven from a single database for security, consistency, and speed, does not exist. I want to see project milestones that deliver what doesn't exist!

Mitigation: First and foremost they are correct. This new system we're building doesn't exist - that's why we're building it. So if you're talking to me about work that doesn't directly deliver the list of requirements, I don't understand why we are wasting our breath.

Here's the trick; to save your personal sanity and preserve your credibility, assume good intent. They aren't saying I don't believe you - they are saying I don't understand how this topic relates to my requirements. Of course, you must connect the dots between the need for usability [in this case] and the eventual delivery of the expected benefits. The system is only as good as the quality of the data going in.

This is important - when talking about issues, decisions, or work that needs to be completed, you most always tie back to stated benefits.

Nature Abhors a Vacuum

Challenge: Blithely ignoring the fact that the executive team has many other things on their plate (see above) our intrepid project manager lays out five major issues and three options for each one. I, as CEO, got to where I am by Being Decisive and Making the Call - so if you're giving me the options, I'm going to start telling you what to do because 1) you're asking and 2) I need to move on to the next agenda item.

Mitigation: Heed that classic management one-liner - don't come to me with problems, bring me solutions. We all get paid plenty of money to solve problems, and it really drives execs nuts when all we do is define tough problems - and look to them for guidance. Believe me, most organizations will massively empower you to show some leadership and make your own decisions!

Not to worry - there are many control mechanisms in place to guard against bad decisions, but you need to control the message and flow. When presenting to the execs, don't lay out options followed by your preferred choice - it sounds too much like you're asking for their choice, that the project is dead in the water without their decision. A better method is to present your choice as the only way to proceed (this makes sense based on X and Y and Z). At this point, you can do a few quick bullets on the options, subtly giving the executive team an opportunity to ask probing questions and suggest alternatives. Trust me - if they have any issues, they will drill into these options and dissect your rationale. But when they don't ... progress!

The Myth of Executive Omnipotence

Challenge: In many companies, the executive team holds a magical sway. The staff adheres to their every whim; reworking this project "because the CFO said we should", reprioritizing that project down the list "because the CEO wants it that way". I love asking the "stupid" questions ... like Why does this need rework? What exactly does the CEO want to see as a deliverable from this team?. If you find yourself pondering (hmmm, I'm not sure exactly what he asked for, but he was pretty adamant - so we better deliver)

Mitigation: If your neighbor stops by to borrow a ladder or chat up the Fire game this weekend, you might have no idea that they are a COO or Vice President; she's just a regular person like you and me. So why would you grant them magical status in a workplace environment? Look, if you don't understand what they want, just ask for some clarification. You can make the [very safe] assumption that they are good men of business, and will react predictably to a business-based conversation. We had two options; here are the costs, benefits, and risks, and here's why were going to pick option one. If your assumptions differ from theirs, why can't you have an open conversation to challenge those assumptions?

Sometimes I think people are too self-conscious; no one wants to appear stupid and ask the General Manager to elaborate on what they're saying, because they aren't being very specific or they're making a logical or factual mistake. This is entirely possible, even probable - they may not understand the implications of what they're asking for, but since you the project manager, are defining problems not solutions, and since I've got 16 other things to do between now and quittin' time, I'll just start making decisions. I've seen plenty of projects get blown out of proportion and swerve down strange side routes because the executive said something, the team took it to be the One True Way To Go.

Update them on what they are expecting to hear about
Keep it to the relevant level of detail
present solutions to any problems that pop up
Anticipate some questions ...
... but don't offer up the details until asked
If you failed to write down what they asked for, follow up ASAP
... and figure out how to listen better next time!

Previously ...

Fractal Business Issues - Katamari Damacy at Work (February 25, 2005)
Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
Funny, how techies talk to each other (September 11, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
Five Under-Emphasized PowerPoint Best Practices (May 7, 2007)
Defining the Business Value of a Project (October 25, 2007)
Measuring and Reporting IT Value (1 of 2) (November 16, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Five More Realities for Driving Business Value from Technology (January 30, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Butting In to the Conversation: PM Communication Tools (February 26, 2008)

Technorati Tags: best practice, business value of IT, presentations

Politically Correct Euphemisms in IT - Translated!

2008-05-26T12:33:00.001-05:00

Politically Correct Euphemisms in IT - Translated!

I recently attended a professional seminar, and noticed a propensity for politically correct euphemisms to describe life in corporate IT. This was a typical group of IT professionals, representing a variety of companies - small and large, public and private. As with most group meetings, we started with a trip around the table; quick introductions, plus some highlights of "what's hot" for IT these days. The careful language wouldn't fool the experienced; however, a casual listener might see the knowing smiles on the nodding heads and think that we were either participating in a great conspiracy or dazed from too much coffee.

As I aspire on these pages to improve the quality of communication between IT and business, I feel duty bound to provide this partial translation page - what they say versus what they mean.

The project has been a challenge ...

We bit off way more than we could chew, and will probably blow the budget by 50%

We are considering ...

We talked about this one over beers, but there's no chance in heck of going forward ...

... looking at opportunities for SaaS ...

We're under budget pressure, and are desperate to say something to keep Finance off our backs about data center costs.

The database is growing rapidly ...

We massively underestimated growth rates, and are scrambling for capital to buy more disk.

The developer is quite aggressive ...

... they don't have time for documentation, debug in production and have polluted their workstation with multiple versions of component libraries that will cost millions to roll out

We did a pilot in CRM, and now we are comparing to salesforce.com.

... that's gonna stress us a bit ...

Another six months of nights and weekends? Good thing my resume is up-to-date ...

We have managed to create 18 instances of the ERP

We've implemented (insert module name here) - which is ... interesting

This thing has more bugs than a VW convention in a swamp; we're in a first name basis with the core development team, and half the code has our IP in it.

... using the latest and greatest, and some we're still waiting on ...

The rep sold us vaporware, and we've already maxed his voicemail box demanding a delivery schedule (or a refund)

... after a lot of pain, discussion and analysis ...

we are on our fifth attempt at implementing, but the business sponsor can't cancel because he's overcommitted on the ROI

It's a legacy system, home grown, and its old.

We've gone through five lead developers, the original author is playing shuffleboard in Florida, and if the disk crashes we're hosed because we don't have the source.

This is going to drive quite a lot of work.

I'm stunned at how poorly thought out the project plan is ...

[ long list of acronyms and letters]

We are rabid technologists ... by the way, how come executive management doesn't invite me to meetings?

We're revisiting [something] (strategy, software package, implementation approach) after the acquisition ...

We're going through a process of stabilization before rollouts continue.

The biggest challenge is the cultural shift.

Technical implementation is equivalent to C:INSTALL, but we'll be in training classes for months.

We experienced a little bit of a hiccup.

When the install dialog said "Are you sure?", I experienced a giddy sense of optimism that was quickly countered by a suitably horrible sound from within the drive ...

It's a learning opportunity ...

It's a chance to hone our skills at backpedaling, debugging on the fly, and byte-level disk sector editing.

We met our service level objective

Good thing we sandbagged the the target run rate.

... and this is what's going on ROW (Rest of World) ...

We don't like international travel, so our strategy stops at the border ...

... (refers to ) my soon-to-be partner (acquisition/joint venture) ...

Regional translations may vary; I invite your input on additions and variations ...

Previously (on the lighter side) ...

I have nothing to say and I am saying it and that is poetry (April 6, 2005)
Bug bad, bug good, bug Bug (May 18, 2005)
A blast from my past - game programming for the TRS-80 (October 5, 2005)
Hand writing recognition - harder than colored bubbles (November 19, 2005)
Custom Code Bad, Custom Code Good - Notes for your Software License Agreement (February 26, 2006)
Guidelines for Success with your Skunk Works project (June 19, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
Funny, how techies talk to each other (September 11, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
There's a pony in here somewhere ... (January 1, 2007)
No, you mean Smart as a Bag of Hammers ... (January 9, 2007)
How to Cheat at the PMO Prioritization Game (December 14, 2007)
How to Win at the PMO Prioritization Game (December 18, 2007)
BigDog: Impressive Robotics (March 21, 2008)
Why are those Old Programmers so slow in picking up on the Intarweb? (April 6, 2008)
There ain't much IT in IT Management (May 7, 2008)

Technorati Tags: best practice, business value of IT, CRM, development, innovation