cazh1: on Business, Information, and Technology

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

Labels: business value of IT, development, documentation, people management, tech management

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

Labels: business value of IT, people management, presentations, project management, tech management

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

Labels: business value of IT, Knowledge Management, people management, presentations, project management, tech management

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

Labels: application development, business value of IT, CRM, development, innovation, people management

When is a project a Project? How to prevent the buildup of backlogged requests

I just wrote something up (internal wiki) that I thought was common knowledge, but I think it's one of those soft-skills things that makes total sense once you hear about it - but somebody needs to tell you.

I think of one of the reasons that IT (at times) intimidates the business - or why IT gets the cold shoulder when it comes to process improvement efforts - is that we can get a bit too wrapped up in the Art and Science of Project Management. It's hard to build that business-savvy image when every new idea that comes your way is met with a 12-month waterfall Gantt, a copy of the PMBOK, and a formal sign-off sheet.

Howzabout a little common sense first? When you hear about an interesting idea from someone in the business, spend some face time with the requestor. E-mails and phone calls will not suffice; you can't build a relationship that way. Have a conversation about what they want vs. what they need ...

Sanity Check: Do they want something huge? Impossible? Impractical? is a great idea, but completely out of line with current corporate strategies/priorities? If so, help them understand they are boiling the ocean, it's overkill and/or not likely to get worked on in the next 12 months. If they agree that this is a bit of a stretch - hey, you're done! You've successfully stopped a bunch of needless administrivia work before it even started!

If they still think it's a great idea, consider capturing the magic by putting together a simple (i.e. quick) Project Charter document, and adding it to your "master list" of projects. Then, immediately put the project on Hold. It will be in your database / list forever, we won't lose track of the Great Ideas embedded within ... but it will be off of our immediate radar screen.

Training Issue: Are they asking for something that can be done in a different way (ie. shooting rabbits with a bazooka)? Maybe they don't understand all that (insert your favorite ERP here) has to offer. Can we solve their request with some training?
Quick Hit: If they're asking for something that is twenty effort hours (or less), has minimal impact on a small number of people (ie. no training will be needed), and could get taken care of over a few days/weeks - consider it "filler work", and don't bother creating a formal Project for the effort. The business will love that you're delivering value without bureaucracy. Your brain will relish the chance to fill-in the dead time between meetings. And, your boss will/should dig it because it's lagniappe - that little something extra. Sometimes, all they need is a report tweak or a simple data download ... Web 2.0 is not the answer for everything.

Caveat: Don't let this become the way that everything gets done. If a project is big enough, you should go through the proper level of rigor - it ensures that your efforts will be sustainable.

The Real Thing: Ok, if you've made it this far - this idea is good, it's not too small, will involve a number of IT and business resources that need coordination and communication - i.e. Project Management - then yes, you need to follow your IT group's standard process. No shortcuts (from here on out ...)

Previously ...

End-around the Prioritization Process (August 14, 2004)
Pendulum swings - Santayana says ... (May 12, 2005)
Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
Open Source as bargaining chip - driving business value of IT (October 30, 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)
The "Army Rangers" model for IT Professionals (January 2, 2006)
No, you mean Smart as a Bag of Hammers ... (January 9, 2007)
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
Defining the Business Value of a Project (October 25, 2007)
PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
How to Cheat at the PMO Prioritization Game (December 14, 2007)
How to Win at the PMO Prioritization Game (December 18, 2007)
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)

Technorati Tags: business value of IT, PMO, project management,

Labels: business value of IT, PMO, project management

There ain't much IT in IT Management

This morning, I caught myself looking back at the last week of meetings, e-mails, and conference calls, and I experienced a minor epiphany. If I published a detailed diary of the ebb & flow of proposals, debates, and commitments from the past few days, I could successfully deflate the management aspirations of 80-90% of the technical folks I know. Contrary to what many might think, there's not much IT in IT Management.

Ok, that's a bit of an overstatement; I couldn't do this job effectively without a solid grounding in the technology under discussion. However, I expect anyone with a similar role (intermediary / facilitator between business and IT) would agree that it goes well beyond compilers, load balancers, and user interfaces. We talk about fundamental business process, not just specific IT projects. When presented with new ideas/approaches, we question some previous decisions while reaffirming others. We use the simple calculus of cost-benefit to make the call between multiple options; the magic is in defining the problem clearly, identifying the costs accurately, and enumerating the benefits fairly & impassionately. (Revenues will increase or costs will decrease, and you'll see it on the bottom line by the end of Month X).

For every organization I've worked with, those conversations are never black-and-white, always shades of gray. Here's a scattered sampling from the week ...

Where are the resource constraints?: For Project Stepstone, we used to think IT was the constraining factor, but now that we have a reasonably detailed plan, it's clear that (operations / finance / sales [pick one]) is overcommitted. How can we line up the top five projects and force rank them? Alternatively - do you have similar Level of Effort (LOE) estimates for these other projects and functional areas? Or are you estimating conservatively / being too pessimistic?
What's this really worth?: Are you going to justify Project Bedlam on hard benefits or soft benefits? And when I say hard benefits I mean you will see a material impact to your bottom line, in the current fiscal year. Can't think of any? Let's work through some examples ...
Agile vs. Waterfall: You want to talk about the "home run" Project Aaron, but I think your best bet is a flurry of singles and doubles. Let's be practical - we need to deliver Project Carew, Project Ripken, and Project Gwynn just to manufacture some time in your day, so you can effectively work on The Big Bam.
How will we know when we're done? What does success look like?: Sometimes it's a struggle to drill past the one-liner, "worthy goal" statements and get to specifics. Integrating our processes is like motherhood and apple pie, but give me a target like increase revenue with key customers by 5%, slash time-to-market for new products by 30%, or drive down inventories with increased forecast accuracy: these are concrete deliverables we can use to drive a tactical plan.
When can we start?: Project Criswell has a detailed plan with tasks, resource assignments, & effort estimates. We have a full cost picture, including capital and expense. We have walked through the change management issues (ie. who specifically will be impacted by this project). We've dotted the I's and crossed the T's - what will it take to get a "go"?

There has been little or no "classic IT" in any of these conversations. No mention of program requirements, data flows, system throughput, database tuning, etc. There is strong business focus, but just as much effort is expended simply in making sure estamos en la misma jugada - we're all on the same page.

This is a consistent modus operandi in all of the companies I've worked with; I don't think it's unique to any company in the more traditional industries, although I would assume high-tech or consulting firms might approach things differently. And, I'm fairly confident that this is why many died-in-the-wool technical folks have little interest in upper management. It's all about semantics, gray areas, and wading through varying levels of understanding to find those nuggets of truth that everyone can line up behind. Its not about winning arguments - it's all about bringing groups of people to the same place as quickly as possible, but doing it without forced acquiescence. Compromise and collaboration will do wonders for commitment when the project hits a rough patch.

This process drives most people in IT nuts - and its not just those with aspirations to upper management. There are plenty of IT groups in corporate America, just chomping at the bit to get something accomplished, to get under way and start delivering real benefits. All of this debating and restating and reformatting appears as an overdeveloped sense of conservatism and an unwillingness to make change. Just make the decision and get out of my way - I'd be done already if you'd just pull the trigger ...

As far as I'm concerned, however, this is where the real fun of IT is. Understanding - really understanding - the problem and the path to the solution is great; helping other people come to that same understanding is really a kick. Catching that glint in their eye when they've taken ownership - they know they're driving a project that delivers big-time benefits - I dig it. It's like the toughest programming problems - the brilliant architecture hinges on one critical hack, and I'm the one who discovers the solution.

It beats working for a living!

Previously ...

End-around the Prioritization Process (August 14, 2004)
System not system (November 14, 2004)
Fractal Business Issues - Katamari Damacy at Work (February 25, 2005)
Does IT make you productive (or, are you an existentialist or a fatalist)? (February 26, 2005)
Communicating Complex Technical Concepts (March 21, 2005)
If you want to be more than a programmer, stop programming (April 8, 2005)
Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
Sometimes analogies work amazingly well ... (July 14, 2005)
Of course we can pay for that ... if it makes business sense (November 7, 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)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
War Stories from the Change Management front (August 21, 2006)
Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
Defining the Business Value of a Project (October 25, 2007)
Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
Five Simple Rules for Project Names, plus Four Sample Lists (January 7, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)

Technorati Tags: business value of IT, people management, PMO, project management, tech management, technology

Labels: business value of IT, people management, project management, tech management

Desperately Needed Features for eMail Clients/Servers

Via Knowledge Jolt, here's an article from KM world with some interesting statistics about folks engaged in enterprise search - but it was a tangential quote from the author that caught my eye. When asking corporate knowledge workers about using public Internet search engines, she found that ...

... although only 2 percent [of corporate searchers] said they used the company intranet, 13 percent stated that they were looking for internal company information. That's puzzling.

Not puzzling to me! They're looking in their e-mail inbox!

It's a common hassle of IT departments - mailbox management (and the lack thereof). Everyone's inbox seems to have thousands of documents, gigabytes of information, and zero organization or structure. There are a couple of interlocking problems here:

Backup: IT is typically expected to cover everything - and after a few years, a few thousand e-mail accounts, and a few gigabytes apiece, well that's an awful lot of tape. More to the point - your backup window gets smaller and smaller, as you watch tape after tape load up with what you know are incredibly redundant inboxes.
Upgrades: Heaven forbid you try to convert from one mail server to another, or go through a major upgrade. The migration process will go on forever, because you have to convert all of that ... stuff.
Document Retention Policies: Something new from last year - the idea that a company must be able to produce any e-mail / electronic document requested by a court. Please, no eMails (IANAL) - I'm not up on all the details here, I just know this is one of the reasons why we can't simply delete all eMails older than six months.

To solve problems 1) or 2), IT departments will attempt to impose a size limit of a few gigabytes. This will be met with a few typical reactions ...

10-15% of your users will far exceed the targeted max inbox size. This is the typical Pareto situation, where the storage needs of a few outweight the needs of the many. Worse yet, this group is typically composed of the Marketing department (huge attachements), everyone in Legal (never delete anything, lots of document scans) and a collection of significant Executives (including the CEO) who get cc'd on everything and have zero time or interest in organizing ephemera.
Invariably, you'll get pushback along the "disk is cheap" line. Last month I bought 750GB of storage at Best Buy for $180 - why can't you throw some cheap disc in the old data center? Unfortunately, those that have time to provide these helpful suggestions typically don't have the interest in hearing about the growing stack of backup tapes.
Bottom line - there's simply no good business case for taking time away from anyone's busy day to organize their desk; they either do it or they don't. Mailbox quotas are IT's way of trying to tell you to get your life in order - and that is pushing rope, completely ineffective unless the person actually wants to change. It doesn't grow revenue, and it doesn't save cost (well, not much).

Now, I don't have any ultimate answers here, but I am trying to lay out the basic premise behind what I think are two very simple ideas that would have a huge impact on the growth of corporate America's eMail-boxes. I gladly invite someone to tell me why these things aren't features of every mail server; of course, I'd rather have someone to tell me how to get this done!

Proposed: Eliminate the Reply All feature: Or, at least make sure the default option is Reply to Sender, and put at least four mouse clicks and/or keystrokes between the casual eMailer and the option to share their wisdom with their cohorts on the To: line. We've all seen annoying threads expanding in our inbox - it must be the default! I say that only partially in jest - I have accidentally hit Reply All a few times - nothing too embarrassing, but it was, a bit too easy to make the mistake.

Proposed: When replying to a e-mail that sports a file attachment, mail clients should delete attachments from the reply by default. It makes little sense to reply to a note and return the original. If you've made changes, you'll be attaching your updated file anyway. I've seen way too many e-mail responses that say, in effect, "I agree". No need to send it back, just tell me you're OK with this. Of course, they'll hit Reply All (see above) because for some reason, I need to be informed that you agree with a copy of the thing I already have a copy of ...

These two options, I believe, would quickly eliminate the majority of useless duplication in corporate eMail servers. My last suggestion, is less about prevention, more about cleaning things up. Of course, I wouldn't be surprised if something like this already exists; I can even imagine how to write it. I just don't have the time ...

Proposed: I want a utility that scans each mail thread in my account, and selects the earliest occurrence of an attachment. Then, the thread is traversed, and all duplicates of that document are replaced with a text reference to the e-mail that contains the original. A simple concept, this would certainly save me a lot of manual effort needed when cleaning out my own inbox.

Any other simple ideas out there for mail management?

Here are some more recent eMail stuff from my blogroll ...

Lifehacker: Top 10 Email Productivity Boosters
McDonald: Questions to Ask Before Replacing Corporate Email

Previously ...

Another Spam Graph - The Impact of Spammers Changing Tactics (September 17, 2004)
Spam Graph redux (nice filter!), and an interesting meme I stumbled upon (May 24, 2005)
Hopefully, my last spam post (June 8, 2005)
eMail on Blackberry Changes Definition of Acceptable eMail (September 19, 2005)
IMAP Gmail Reinforcing the Drive to Web-based Productivity Applications (November 3, 2007)

Technorati Tags: application, best practice, development, innovation, Knowledge Management, productivity

Labels: application development, business value of IT, development, Knowledge Management, productivity, technology

Do you want it good or fast? Prioritizing Time-to-Value over Requirements

I have a background in software product development, iterative "methodologies", and the sort of fast-twitch life cycle that characterizes entrepreneurial startups, high-growing businesses, and "lean" process improvement projects. Unfortunately, this style is also favored by departmental developer wannabes, sloppy coders, and impatient Gen-Y newbies that want to apply a consumer products mentality to corporate IT.

<aside>Yes, I'm throwing a bit of a challenge out with that last statement. I understand that as the demographics of my IT team changes, management style must change as well. However, notwithstanding CIO Magazine's recent deluge of articles urging oldies like me to "get with it", and embrace Web 2.0 flexibility, there are certain immutable facts that fly in the face of the recent college graduates urged to apply social networking, text messaging, and torrent-enabled IP sharing to the 9-to-5 grind ... but I'll save that for a later post ... </aside>

The real challenge is understanding how to introduce this new and different way of thinking (about projects and project delivery) into an environment rooted in audits and controls, waterfall methodologies, and tightly integrated ERP. Nothing wrong with any of these - in fact, for work in and around your run-the-business systems, there's nothing more comforting than the rigor of requirements, testing, and a controlled promotion process.

Still, many organizations focus on the wrong legs of the Iron Triangle. Let's assume that budget, if not absolutely fixed, is at least severely constrained (again, we're not talking about a fast growth company that has money to burn). At this point, the typical IT department - laboring under the twin misconceptions that the customer is always right, and the business understands the difference between wants and needs - dutifully captures all requirements, and work commences until there is nothing left to do. With budget and requirements "fixed", time is the variable, and projects go on for months.

I don't mean to sound cynical - sometimes it's not a question of kitchen sink requirements (as in, "everything but the ..."). Feature creep can also set in when folks want to develop code to test for every scenario or use-case. Even something as simple as adding type codes for a given transaction; believing in the power of metrics, folks will come up with a descriptor for every conceivable exception - regardless of the frequency or relevance.

I think the biggest difference between these organizations and their iterative brethren - startups, fast-growth, and "lean" organizations - is a focus on time to value. Established companies have predictable sales cycles, quarterly statements, and six month planning horizons; it's not about speed, it's about getting it right.

Established companies start to struggle with time to value when their environment changes. This is when a subtle change in project management style can go a long way towards liberating the locked-in value of these powerful organizations. Focus on that third leg of the triangle, and learn how to manage a project to a date. I have to be done in 60 days - what can I get done in that much time?

Sometimes this leads to a counterintuitive decision. For example, a make-to-stock company may have established a Microsoft standard for desktop systems, but a new line of custom engineered, make-to-order products may need to hire in a team of Macintosh-wielding product designers that must be productive on Day 1. In the long run, I may need to replace their new workstations, but I'm certainly not going to slow down the launch of a profitable new line while my standards team goes through a lengthy RFP and vetting process.

Another common mistake - or maybe a defensive mechanism for those well-grounded in the status quo. Sometimes people “give up” on the idea of getting projects done in a short amount of time – “nothing happens quickly here”. I maintain that we give up on the idea of getting it done quickly, because we're not giving up on the demand for 100% requirements. If we insist that the work must be done in 60 days, we will have to give up some of the nice-to-haves.

This is the big change management challenge before us - prioritize time to value over requirements, and focus on the 20% of the work that will deliver 80% of the value.

Previously:

Customer Service, Roles and Responsibilities (September 25, 2004)
Things for the DIY programmer to consider (March 14, 2005)
Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
My Favorite Paradox (August 13, 2005)
Misapplying the Pareto principle (January 7, 2006)
War Stories from the Change Management front (August 21, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
There's a pony in here somewhere ... (January 1, 2007)
No, you mean Smart as a Bag of Hammers ... (January 9, 2007)
Another caveat for the erstwhile agile developer (January 15, 2007)
Defining an Effective IT Metrics Framework (January 21, 2007)
More on (sic) experience with wikis (January 31, 2007)
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
Consarned whippersnappers (Generational Diversity) (May 20, 2007)
Five Key Skills for Successful Project Managers (June 18, 2007)
Tactics for Controlling Project Scope (January 5, 2008)
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)

Technorati Tags: business value, entrepreneur, Project Management, tech management

Labels: business value of IT, PMO, project management

Five More Realities for Driving Business Value from Technology

Dennis McDonald's recent post listed Ten Realities of Managing and Using Technology to Generate Business Value. I think a few of these items need some elaboration ...

Implementing a technology based solution without understanding the costs is a big mistake

Total Cost of Implementation

Recurring Costs

Total Cost of Ownership

Just because you adopt a new technology doesn’t mean the users of your old technology will disappear overnight
Many technology based projects are mostly about business and process change, not about technology
Technology is usually the easiest part of the project - read a manual, spin up a few servers, type in C:>INSTALL ... how tough is that? The difficult part is getting people to use the software, to change their behavior to take advantage of the new process. This is possibly the number one reason why IT projects fail - technologists focus on writing / installing software, instead of business analysts driving to implement a system.
If you’re not in the technology business, you probably should leave developing new technology to others
Every other year, without fail, I will run into yet another person in the business who thinks their idea for a productivity-enhancing standalone system, web service, or ERP bolt-on is so brilliant, we could sell a million of 'em, become a new profit center for the company. Typically, these folks have no idea of what it takes to run a software business ... they see distribution costs are miniscule and revenues are huge (because, of course, they'll be able to charge (and collect!) ERP prices ...). Unfortunately, they fail to realize the ongoing cost of support - who's going to take the phone calls, train the users who didn't read the manual, and deal with the myriad of one-off client configuration problems that prevent WonderWare from starting up.

... and here are five more Realities to add to the list ...

Getting rid of old technology should be a requirement: Woe to the IT department that does not manage the growing complexity of their data center. You can't keep adding the next server, interface, or application without consciously remembering to turn off and decommission the technology it replaces, else you'll never get out of the death-spiral of monitoring and patching obsolete technology that stopped delivering value a long time ago.
"Standing pat" is a valid alternative: It may sound like heresy, but when faced with large recurring maintenance fees or hefty upgrade project, IT must always present the do-nothing option - especially for companies strapped for cash in the short and/or medium term. The business may choose to stop paying maintenance on the mission-critical software, but that (typically) does not mean they have to turn it off. It just means no more patches or telephone support, and hefty back-maintenance charges if they ever want to upgrade in the future. There are many business scenarios where this would make sense - you must always provide it as an option, else you will be perceived as a techie, not a business-person.
Automate a mess and you get an automated mess: Not sure where I first heard this

Subscribe

Categories

Previous Posts

Archives

Networks

Online Chat

cazh1: on Business, Information, and Technology

Saturday, June 28, 2008

IT and the Business are Closer Than You Think

Thursday, June 12, 2008

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

Friday, May 30, 2008

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

Monday, May 26, 2008

Politically Correct Euphemisms in IT - Translated!

Wednesday, May 21, 2008

When is a project a Project? How to prevent the buildup of backlogged requests

Wednesday, May 07, 2008

There ain't much IT in IT Management

Sunday, April 20, 2008

Desperately Needed Features for eMail Clients/Servers

Sunday, February 10, 2008

Do you want it good or fast? Prioritizing Time-to-Value over Requirements

Wednesday, January 30, 2008

Five More Realities for Driving Business Value from Technology