Sponsored Links

jobs!

Online Chat

Use the window below to chat with me (if I'm online ...)

Use the edit nick field above to let me see your name.

cazh1: on Business, Information, and Technology

Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...

Thursday, June 12, 2008

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

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 ...

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , , ,

Labels: , , , ,

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

Thursday, June 05, 2008

Opportunistic Insights from the RSS Stream

Opportunistic Insights from the RSS Stream

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

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

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

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

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

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

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

Show vs. Tell

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

Previously ...

Technorati Tags: , , , , , , , , ,

Invisible Technorati Tags: , , , , , ,

Labels: , , , , , ,

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

Friday, May 30, 2008

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

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 ...

Wednesday, May 21, 2008

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

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 ...

Technorati Tags: , , ,

Invisible Technorati Tags: , , , ,

Labels: , ,

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

Wednesday, May 07, 2008

There ain't much IT in IT 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 ...

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , , ,

Labels: , , ,

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

Tuesday, February 26, 2008

Butting In to the Conversation: PM Communication Tools

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.

(Topic) The Right Tool for The Job - depends on the Job

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.

(Topic) The Perfect Tool for The Job in Unlikely - but Opportunity Knocks ...

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.
Previously ...

Technorati Tags: , , , , , ,

Labels: , , , , ,

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

Monday, February 18, 2008

Rules of Golf - Project Prioritization Process Needs Clear Documentation

Success, Failure, and Insights after 12 Months of Internal Web 2.0

Different areas of our IT department are using internal blogs, wikis, and collaboration spaces, with varying degrees of participation, readership, and success. Some observations:

Blogging is Easy ...

The blogs and wiki(s) have effectively removed the hassles of capturing and distributing information quickly. One important early decision was to not implement an editorial approval process for the wiki, and most blogs are wide open for public comments. No more excuses or complaints about a lack of documentation; if the explanation is not clear, or needs examples to make it relevant to multiple situations - all are fully empowered to fix it.

Some find the blog to be an easier way of communicating because of the "immediacy" - a sudden insight or pithy observation pops in your head, so you jump on the blog and capture the thought. These are the folks that have had a little insight, and gone beyond the idea of blogs as just an electronic replacement for a weekly status report. It might be difficult if you feel an obligation to say something every day - but if you really understand what you can and should be writing about, you'll probably make multiple entries every day.

... but Empathizing (with the reader) is Difficult

I still get pushback on the blogs - even among the groups that are currently our "best demonstrated practitioners". These folks are generating a decent amount of participation and content - but still not quite enough stuff to be effective. The challenge, it seems, is to get folks to empathize with the reader - a skill that I'm surprised more folks don't have, because many like to complain about what they don't know, or should know, or wish they knew.

Always ask yourself, what did I do or learn today that others would find interesting? No, it's not that the world wants to understand how my day went, or how I'm feeling. But I like to hear when people are starting (or stopping!) projects, or attending meetings and learning about events or decisions that may have an impact on my my work over the next three months. Empathize with your [potential] readers, anticipate their interest, and practice what I call the "beneficial assumption" ...

  • Most people think the same way I do ...
  • ... so I will anticipate what I'd like to hear about my organization, my projects, and my meetings ...
  • ... and write about that

Self-Policing the Content

What about stuff that [possibly] doesn't belong in a blog - even though it's internal? Key thing is to use common sense; the blog entry is just as permanent, and much more public, than an e-mail. Especially when it comes to "negative events'; sometimes the specifics aren't really relevant and don't add much value. Specifics, like somebody made a fat-finger mistake and deleted some data, or opened a hole in the firewall, or copied the wrong file. A blog is typically not a root-cause, problem analysis tool ... it's a general FYI platform, and specifics (especially the negative ones) moght be taken out of context by the readers.

Of course, we note that content should not be limited to all that is sweetness and light. There's nothing wrong with fact-based bad news, but there's a lot wrong with bad news that no one finds out about and then gets worse, or no one learns from. We don't write about this stuff to get folks in trouble, but we definitely do it to prepare, inform and educate.

Communicating is Still an Art

Some folks will rattle on in too much detail, while others are too terse. The fundamental challenge - most folks can write acceptably, but may feel they can't write well - they lack the confidence to capture it on paper. Confidence is something that comes with practice, but mandating participation is not going to encourage spontaneous composition.

Where Are the Comments?

Some folks surprise themselves with a good blog entry, and then become doubly surprised when then get no comments. Bloggers in a closed community / internal blog can't judge themsleves based on numbers and responses that you mgiht see on the Internet - heck, it's taken me two years to get up to about 50 subscribers to my feed [feel free to subscribe, dear reader!].

Previously ...

Technorati Tags: , , ,

Labels: , , , ,

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

Sunday, February 10, 2008

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

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:

Technorati Tags: , , ,

Labels: , ,

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

Sunday, January 20, 2008

Update on Blogs as PM Tools - Tales from the Front Lines

Update on Blogs as PM Tools - Tales from the Front Lines

We seem to be going through a second wave of focus (hype?) in the popular technology press, on the idea of using blogs as an important project management tool. The topic made the cover of CIO Magazine this week - Lynch made a number of interesting observations - interesting because I don't necessarily see the same things in practice:

  • The Reputation Hurdle: While I agree that blogs aren't fully understood by everyone, the folks that need to use them pick up on the concept very quickly. The beneficiaries of project-focused blogs are the folks participating directly on the project, plus other teams that are dependent on the resources or results involved. We still need to present project status to the management level using tried-and-true PowerPoints.
  • Start Small: The biggest reason to start small, and allow the popularity of PM blogs to spread virally, is that you don't have to devote time and energy to develop training material. Folks see how blogs work, eliminating e-mail threads that clutter up their inboxes, and they just get their neighbor to show them how it works. The real power in gras-roots process improvement like this: you don't have to invest in formal training. Time-pressed IT departments typically don't have time to develop fancy training material - and they usually not good at it.
  • Curing the eMail Addicts: Lynch opens up a very interesting door when he connects importance of RSS to the relevance of blogs. I've had a couple of conversations now with folks who can only see blogs as yet another website I need to visit, more information overload to deal with. eMail is a mission-critical system for many companies, partially because people have learned to use it as an information aggregator. Only when folks see an RSS client in action do they really understand what's going on; the blog/website is nothing, but collecting feeds from the 50 projects you want to keep tabs on, and seeing timely updates about them all in one place - that's powerful, and that's when they really "get it".

A Key Observation

We've been using the MS SharePoint template for a couple of different projects (single efforts) and programs (groups of projects in support of a strategic initiative). We've also had an IT wiki in place for almost two years now. It's fascinating to note how different the rate of adoption for these two technologies has been; getting content added to the wiki is sometimes like pulling teeth, but the blogs are taking off in some areas. Even in small teams that sit within 20 feet of each other; postings, comments and responses are plentiful.

After talking with some of these folks, I've realized that using a blog and responding to a post is just like eMail - it's just stored in a database, accessed using the browser, and conveniently linked to the project. The wiki, on the other hand, is Yet Another piece of formal documentation - and who likes to do that?

More and Better Thoughts

I had a few posts on this topic last year, but Dennis McDonald has been consistently posting a bunch of interesting content in this area:

Previously …