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?

• 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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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

posted by James P. MacLennan at 3:37 PM | Permalink | |

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.

• 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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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

posted by James P. MacLennan at 11:24 PM | Permalink | |

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!

• 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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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

posted by James P. MacLennan at 8:43 PM | Permalink | |

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!

• 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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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

posted by James P. MacLennan at 10:11 PM | Permalink | |

The Innovation Generation and User Interfaces

I don't intend for all my posts about Millennials joining the workforce to be anti-youth. There are some significantly good things this new generation can bring to established organizations - ways of thinking that foster innovation and forward-progress in how organizations use information.

For example, let's talk about user interfaces (UI). I'm not an old man, but I remember the advent of IBM's Common User Access standard. DOS-based computers and early GUIs introduced UI variety, and the resulting lack of consistency took part of the blame for systems that were hard to learn (and therefore hard to use). CUA promised consistency, greater productivity and information effectiveness.

Fast forward to the modern Internet era, and it's clear that "common user access" is no longer a baseline requirement for effective use of information. Cutting edge web sites pride themselves on their innovative, engaging, and unique front ends. Every website you see is different, yet it doesn't take people much time to figure out how to order a book on Amazon, browse for peripherals at CDW, or bid on stuff on eBay. These are mainstream Internet users I'm talking about; the tech-savvy are just the ones coming up with a new and different clown suits** for the same old services.

**And by 'clown-suit' I mean 'innovative dynamic XMLSocket/AHAH/AJAX-based exploitative web 2.0 social mashup,' of course. (props to findmemp3)

However ... isn't it interesting that those mainstream Internet users, productively surfing at home, are the same folks in your office complaining about difficult-to-use ERP systems? In this world, UI consistency is not an issue (okay, except when an acquisition is folded inelegantly into another framework). The challenge is with system designers and developers that lack an understanding of what makes a user interface effective and engaging - something that most longtime corporate system developers have never really been trained in.

Not that the newbies (sorry, Millenials) coming in to our IT departments automatically know how to design an effective interface - they are just more open to it, and they understand it better when they see it. Admittedly, "I know it when I see it" is hard to describe and extremely hard to train. However, now I must link to one of the few presentations I've ever been able to get a lot out of without having the presenter present to me ...

| View | Upload your own

Now, I certainly can't explain Kano Modeling and the more theoretical stuff, but it really starts to click on slide 15 when he showed a hierarchy of needs for user interaction. The slides lay out basic ideas that resonate, and terrific examples that you can recognize from your daily travels through the Internet. These applications speak to you, not at you, and make the act of using them a pleasurable experience. Simple stuff like conversational error / warning / guidance messages, effective use of pictures and words, and the value of "less is more".

I think a critical differentiator between an application accessible via the public Internet and the typical internal, corporate application is a fundamental assumption [on the Internet] that you cannot hold your user's hand through the process. The information presented, and the user's experience, has to stand on its own - because it is impossible to know who, when, and where your stuff is going to be used. This raises the bar for usability and scalability, but it's a great model to emulate for internal development in this lean economy.

So how do you make the jump between internally-focused developer and externally-savvy innovator? I'd start with Anderson's presentation - see if it "speaks to you". I think you'll either get it (and your mind will open up), or not (and you need to burn a few hundred hours surfing websites and experiencing the difference).

• Communicating Complex Technical Concepts (March 21, 2005)
  
• Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
  
• A blast from my past - game programming for the TRS-80 (October 5, 2005)
  
• The "Army Rangers" model for IT Professionals (January 2, 2006)
  
• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
  
• Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
  
• Open Source Insights on Enterprise Software Business Models (March 14, 2007)
  
• Lighten Up, Francis - Loosen Up That PowerPoint (April 14, 2007)
  
• Consarned whippersnappers (Generational Diversity) (May 20, 2007)
  
• Butting In to the Conversation: PM Communication Tools (February 26, 2008)
  
• The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
  
• The Innovation Generation - Communication Styles (April 1, 2008)
  

Technorati Tags: design, development, innovation, Web 2.0,

Invisible Technorati Tags: cazh1, FEI, Front End of Innovation, James P. MacLennan, jpmacl, MacLennan,

Labels: application development, design, development, generational diversity, millenials, tech management, Web 2.0

posted by James P. MacLennan at 11:29 PM | Permalink | |

Why are those Old Programmers so slow in picking up on the Intarweb?

A significant difference between us old-line IT coders and the new graduates is the variety of our platforms and tools. I'm not talking about the large number of languages and tools learned over the course of a career - we all have a healthy collection of certifications and acronyms peppering the bottoms of our resumes. I'm talking about the amazing array of stuff required to get development done on a single project, "right now".

Over the past few weeks, I've been doing a little development at work. This is my idea of fun - in between the PowerPoints and project status meetings, I try to sneak in a little hack or two. Actually, I'm not doing the heavy lifting on this one; I'm working with one of the guys on my team, and we're putting together some ASP code to generate RSS feeds from the SQL database we use to track our projects. He's done most of the raw research and the base coding, I'm just prettying up the final package.

As a department, we're moving towards Microsoft as a strategic platform, but we're certainly not there yet - so this is definitely a skunkworks-type project. For this "fun stuff", we're using technologies that will plug nicely into our general strategic direction, but at this point there are no standard toolsets or integrated development environments in broad use.

So, to get the job done this afternoon, I've been cycling through the following ...

• In window #1, editing the .ASP file with Crimson; source files are sitting on the development server
• In window #2, testing code using IE ... no integrated debug environment for my ASP syntax, but I manage (just a little trickery - switches flip between RSS and HTML output)
• This is just debugging the basic code - to validate the RSS XML, I View Source from IE (opening window #3) and cut and paste into the W3C validator (window #4)
• For the SQL queries and database hacking, I've got window #5 for Enterprise Manager and #6 for Query Analyzer
• After debugging, I push to the test server manually, using File Explorer in windows #7 and #8
• Everything looks great, so I switch to window #9, which has another chunk of ASP that generates custom URLs for the RSS feed (we've added selectivity, aren't we crafty?)
• For the final test, I have RSS Bandit open in window #10. I create multiple new feed URLs (#9) and add to the Bandit config, to see what I get
• If I made a syntax error in the RSS (missed something between #4 and here), I have to flip back to window #1 to clean it up
• Oops, almost forgot ... like any good coder, I've got TFMs open, but it's not just one manual- window #11 is my multi-tabbed Firefox, Googling all sorts of sites to get references for RSS, ASP, and SQL

Sounds crazy, I know. I could/should go out and get Visual Studio or something. But like I said, we're not fully in production in this Microsoft development environment. We're innovating, right?

I've done open source development on my own in the past, and it's much the same thing - multiple different platforms, tools, and languages. For example, when working on my own site, I'm fixing configuration files and writing code in HTML, CSS, PHP, and mySQL. To get things working, I'm dealing with the configuration files for Apache, Eclipse, PHP, and mySQL. Edits in Eclipse and Crimson, pushing around source with FTP, fighting firewalls and routers, developing in Windows while production is in Unix.

This madhouse of multiple tools, languages, and platforms probably sounds quite normal - if you've been working heavy with open source and/or Web 2.0 for a few years. But imagine presenting this to legacy IT folks, working in their version controlled, standardized environments. The typical "road to the future" brings five new technologies, three new IDEs, and one or two basic system architectures that are all very different from tried and true.

Does this mean you can't teach an old dog new tricks? Not at all - most are quite anxious to learn, and have done so continuously over the years. However, this is all starting to feel like the first time we switched from procedural languages (COBOL, RPG, Pascal, Fortran) to OO and event-driven stuff (Visual Basic, PowerBuilder, SQLWindows). We went from offense to defense, from being controlling and orchestrating to reacting and trapping. Not that it was bad or wrong - just different.

Does this mean the experienced coder is washed up, and has nothing to contribute? Ask the folks in Big Pharma, having dealt with the FDA and validated systems. Ask the folks working with Finance in public companies, having dealt with SarbOx. Healthcare and HIPAA. Retail and RFID. Not to mention having to debug a lot of other people's code, and knowing when to step through or just refactor.

Running to the future, juggling multiple multilingual windows, and demonstrated facility with the newest tools is all good, but it's just one of many attributes that determine who on your team is worth 50 others. Have a little patience ...

• Things for the DIY programmer to consider (March 14, 2005)
  
• Tracking patent submissions via RSS (June 1, 2005)
  
• Turning a new page, and working on that home development environment (July 27, 2005)
  
• My Favorite Paradox (August 13, 2005)
  
• Analog and Report Magic Log File Formats (September 10, 2005)
  
• Fighting with MS Access and version incompatibility (September 26, 2005)
  
• Digging into open source for a New Big Project leads to Yak Shaving (November 4, 2005)
  
• Code Mover / Transport: Managing source, environments, and deep-diving into multiple technologies (November 6, 2005)
  
• The "Army Rangers" model for IT Professionals (January 2, 2006)
  
• SQL Hack for Reporting Project Phase and Status (December 19, 2007)
  

Technorati Tags: design, development, documentation, hands on, innovation, tech management, technology, Web 2.0

Invisible Technorati Tags: cazh1, FEI, Front End of Innovation, James P. MacLennan, jpmacl, MacLennan

Labels: application development, development, generational diversity, hands on, innovation, millenials, productivity, tech management, technology, Web 2.0

posted by James P. MacLennan at 12:13 AM | Permalink | |

The Innovation Generation - Communication Styles

There've been many articles in recent weeks about the tech-savvy Millennials and their impact on future work. I concede, even welcome the changes that business will need to introduce in response to these new expectations, but I don't see the massive change that some writers seem to think is inevitable. The world will not change to accommodate the Millennials, but relevant and effective new working styles will definitely be adopted where they make business sense.

I will certainly agree that communication styles will change. For example, there will be a greater reliance on (and expectations of) instant and ubiquitous connections - with people, information and technology. IM is already on the way out, and texting is the way to go; my high-school-aged daughters think nothing of racking up thousands of text mails every month.

Unfortunately, this kind of freewheeling message content is going to run headlong into the litigious real-world. Many companies are still struggling over records retention standards and expectations. Public companies will need to maintain some control over messages that could contain proprietary or inside information. Corporate survival and protection from liability are clearly not on the minds of students as they post embarrassing pictures on Facebook pages, and even adults get trapped by unfortunate text messages that come back to haunt them.

Don't get me wrong - I'm a huge believer in alternative messaging styles and flexible collaboration. I've managed and/or participated on multiple "collaborative" teams - people from different companies, zip codes, time zones and countries. Separation by time and space has been a business challenge for years, but you could set up a shared FTP folder, or swap e-mails about projects, as long as I've been working. The teams that succeeded understood the differences between working across the hall and working across town, and moderated their communication styles accordingly, using the best tools available.

The value the Millennials bring is a de facto openness to collaboration tools. To them it's not something new that they need to learn; they expect the rest of us to already be there. Their rude awakening will come when they need to invest some change management time getting us "old folks" to catch up to their fast twitch messaging style; they won't be able to pass us by because we've got the organizational and process knowledge. (that's why we're on the team, right?)

• CIO Mag - Decision Evolution (October 11, 2004)
  
• Fast ticket to getting left behind (February 15, 2005)
  
• International Meetings - Pick a Convenient Time (April 1, 2005)
  
• War Stories from the Change Management front (August 21, 2006)
  
• Consarned whippersnappers (Generational Diversity) (May 20, 2007)
  
• Innovation That Matters - Substance Over Style (January 12, 2008)
  
• The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
  

Technorati Tags: collaboration, design, generational diversity, innovation, Knowledge Management, millenials, people management, productivity, Social Networks, tech management, Web 2.0

Labels: collaboration, design, generational diversity, innovation, Knowledge Management, millenials, people management, productivity, Social Networks, tech management, Web 2.0

posted by James P. MacLennan at 9:38 PM | Permalink | |

Power Outage Follow Up - Observations

A couple of hours after my last post, the power came back on in the building and all was right with the world. My dissatisfaction with Dell battery life was confirmed - I only got in about an hour of work before everything died away. It's clear that my current choice of notebook precludes me from a great amount of truly roaming activity.

On the other hand, I am finally switching from hardwired to wireless connections when in the office - even at my desk. I can switch buildings, work from home, etc. and never change my basic startup process for getting connected. It's a small thing, but I'm all about continuous improvement and the cumulative effect of multiple processs changes over time.

My most interesting insight came a bit later in the morning. After a few more folks got to the office, and there was nothing else electronically to do (thanks to the weak batteries), a small group launched into conversation on a project that was experiencing some issues. I noticed a palpable sense of relaxation while talking - driven, I think, by a unstated assumption that we had no nothing else to do. However, I think the fact that we had no pending distractions (meeting in 15 minutes, other work to get done) plus a severely limited potential for interruption (by phone calls or e-mails), and no diversion of attention (ie. typing on the keyboard while taking part in the meeting) was a significant productivity boost. The conversation was fairly robust and free-flowing - the ideas came easier, the alternatives made more sense.

For team productivity, there is definite value in getting away from the office and shutting off all connections. Freedom plus focus makes a difference.

• Thoughts During a Power Outage - (March 27, 2008)

Technorati Tags: best practice, collaboration, design, Knowledge Management, operations, people management, productivity, tech management

Labels: collaboration, productivity, tech management

posted by James P. MacLennan at 10:36 AM | Permalink | |

Thoughts During a Power Outage

I am sitting in the cube outside my office, connected by wireless to our corporate network in an otherwise darkened office. The power is out - started around 3AM, and it is apparently affecting a large area, not just this building.

• Kudos to the infrastructure team that strung up the wireless access points here - thanks for plugging them into the same circuit that is powering the emergency lights. not sure if that was by design or a happy accident, but coupled with notebooks running on their batteries, we have the ability to get some communication of status out to the world.
• Some concerns about battery life, however - I use a Dell Latitude D620, and it is (in my opinion) really poor at power management. I expect to get about 60 total minutes of work out of the thing - kinda sad if you ask me.
• No affect on my Blackberry - I am sending and receiving just fine. If you haven't checked out Blackberry Messenger, I'd look into it - definitely useful for sending out quick updates to key folks.
• Not sure if it would do any good to call folks on my teams re: working from home - zero insight as to when the power will come back on. I just made an entry into my internal blog, so I suppose if they happen to catch that post (or this one!) before they come in, they can give me a shout on the cell phone to let me know if they are coming in. Use best judgement - if you had a meeting scheduled, for example, I would definitely come in, just in case.
• I just spoke to someone who did make it in - another early bird like me. He heard on the radio coming in that this is affecting a big part of the area.
• I tried to Google for a status update, but am not able to find anything. That might be something nice for Commonwealth Edison / Exelon to set up - definitely a shortcut that I would set up on my Blackberry.
• This is definitely a case for Twitter - unfortunately, that's blocked by our network policy.

I'm having a bit of fun here, blogging at near-real time to capture thoughts. Part of continuous improvement and innovation is capturing learnings from any situation, so this is my great experiment on blogs as news delivery (as opposed to spouting opinions / capturing deep thoughts - my regular meme / schtick).

That's all I know at this time ...

Technorati Tags: best practice, blackberry, blog, collaboration, operations, productivity, tech management, technology, twitter

Labels: blackberry, blog, collaboration, tech management, technology, twitter

posted by James P. MacLennan at 7:02 AM | Permalink | |

Butting In to the Conversation: PM Communication Tools

Dennis McDonald and Lee White are conducting an interesting experiment on their blogs, crossposting a conversation about project management and social media. I'll add my voice, with both input on the topic and observations on the method.

The first part of the conversation talks about whether social media could replace classic project management tools, in terms of communicating project status. I agree with Dennis - you can never get rid of gantt charts, project budgets, and stoplight issue lists. It really depends on who the recipient of this information is; most of my project sponsors are busy executives who rose to the top in the era of e-mail and PowerPoints. Communication is uni-directional - you to them. Team members and external consultants, on the other hand, require bi-directional, collaborative tools, and most expect web-based environments accessible in and out of the corporate network, instant messaging for quick status checks, and blogs for general updates.

Truth be told, the most valuable tools in the project manager's communication kit is typically Ctrl+C and Ctrl+V.

Another one of McDonald's posts lists features a wish list of features for the perfect collaboration environment. It reads like a feature list for MS SharePoint, and McDonald anticipates the reaction well (I, for one, welcome our new Comment overlord ... )

I KNOW that many of these features are already available in off the shelf products. Comments that are thinly disguised sales pitches without a sincere effort to contribute to this discussion will be mercilessly and gleefully deleted.

It must be that time of year - I've gotten a number of calls from vendors in the last few weeks, pushing any number of PMO environments that promise to manage my resources and solve all my prioritization woes. In these times of tight IT budgets, capital investment for new software like this rare - the dollars are better spent supporting the business.

However, all is not lost. The collaboration requirements of most PMOs can be delivered quite nicely with a collection of FOSS tools, MS Office automation, and a little ingenuity. Looking for a low risk project to throw at aspiring web 2.0 technicians and Millennials suffering from wanderlust? How about those developers trying to learn what makes effective user interfaces?

Every PMO I've ever worked with / built up relied all or in part on locally developed tools; the cobbler's children can usually hack up something serviceable. And to borrow a phrase from Lee White - most of the skills for project management and collaboration comes from creating the tools, not having the tools.

(Method) Not the Right Tool for the Job

I'm not sure I fully understand the technology that Dennis has used to combine the text from these blogs, as well as everyone's comments. My first reaction on reviewing the feed was less than positive; like a typical blog feed, it probably puts the most recent entry first - so if you want to follow the conversation, you must jump to the end of the list and page backwards. Of course, once I dove into the content, I got a bit lost. I'm not exactly sure of the order of the items in the feed, but best I can tell, the conversation starts in the middle and then sort of bounces around.

Discussion forum software does better at this task. The start of the conversation appears first; as I move down the page, I can scan the main conversation thread as well as any branches from the comments.

That's the other challenge with this method of capturing and displaying a conversation. There are a number of interesting comments, but I can't figure out how to comment on the comment, nor can I figure out how to add another voice to the conversation.

I've written about this previously; the best tool for the job depends on the type of collaboration you are trying to initiate ...

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

Authors Note: I officially despise ecto at this time. This is the second time that I've written this post - spent an hour and a half on it last night, only to have ecto mysteriously delete my work. I'm switching back to w.bloggar for now - gave up on it a long time ago, but it appears to have gone through some pretty extensive improvements.

• Implementing Intranet on Speed: The Beginning (July 27, 2004)
  
• Communicating Complex Technical Concepts (March