cazh1: on Business, Information, and Technology

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

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

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

Project teams need people that have Change skills:

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

WIIFM?

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

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

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

Previously ...

• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Best Practices for Requirements Gathering Sessions (December 7, 2008)
• KM Overcomplicates: Heisenberg Impact on a VBA Quickie (February 8, 2009)
• Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
• If I Told You a Fractal Solution, Could You Change the CEO's Mind? (December 6, 2009)
• Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)

Technorati Tags: business value of IT, change management, innovation, people management, project management,

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

This post started off as an excuse to experiment with Google Docs, and this really neat feature I discovered - embedding a spreadsheet in a web page as a sharing method. However, it struck me as a potential way to cost justify the time, effort, and expense of implementing collaboration systems with the Most Cynical Among Us.

We've all been in large meetings, with tens of people from the project team, along with the expensive consultants, sitting around a table listening to the project manager read their slides to us. The meetings always get scheduled for a full hour (it's the default in our calendaring system!), and everyone feels the need to speak, if only to make sure their voice has joined the chorus of agreement.

However, many of the Most Cynical Among Us have observed the large number of people in the room, and asked the question "How much is this meeting costing me?" It's a worthy exercise to go through ... so I whipped up a little spreadsheet model to quantify the hard and soft costs ...

It doesn't take long to play with the model and see the dollars add up; even if you don't believe in tracking "soft costs", the amount of time spent in meetings can get really big, really fast.

Are status update meetings inherently a waste of time? Absolutely not - communication is critical, and most organizations typically don't do enough of it. An exercise like this just puts the potential cost, in time and money, in real terms - and reminds us to focus on maximizing that investment.

Can this meeting be avoided? Collaboration platforms (blogs, intranets, etc.) let us update the team virtually; people can get the information when it's most convenient for them.

Are we communicating effectively? Sometimes, face to face communication is required and preferred - especially when you need to monitor how the message is being received in real time. Hence the broad focus on effective presentations and impactful communications ...

Look at the cost of your last meeting - did you get your money's worth?

PS: I welcome any suggestions for improvements to the model -  to request edit access or to get a copy, send email to jpmacl_docs@cazh1.com.

Previously ...

• Corporate Web 2.0 is Spreading - Here comes the Blog (May 15, 2007)
• Hidden Gold in Automating Recurring Processes (May 28, 2007)
• Communication is the responsibility of ... (August 19, 2007)
• Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
• RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
• Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
• Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: business value of IT, collaboration, hands on, people management, presentations, productivity, project management, Web 2.0,

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

I've received input from ten companies so far - large and small, with all sorts of ERP systems. If you care to add some information, I'll thank you in advance, and add it (sufficiently anonymized) to the summary results document (download from here).

Here are some of the findings / observations from the summary ...

Master Data Domains

The types of Master Data called out included the usual suspects - Customers, Vendors, Finished Goods, Employees. Others mentioned include Metadata, Packaging / Tooling (components), and Indirect customers (like Payors in managed care, or Buying Groups in B2B). The primary systems in scope included SAP, Oracle, JDEdwards, and QAD, joined by an eclectic mix of legacy systems and point solutions. Secondary systems called out included Siebel, JDA/Manugistics, and ADP (payroll) - plus more legacy / home grown / departmental apps.

Master Data initiatives varied, based on where the "current pain" is - R&D / engineering, CRM / Customers / Contracts / Pricing, and Finished Goods / Logistics were named by different companies as their particular focus areas. Other important considerations were things like geography (North America vs. ROW), and business structure (Enterprise vs. business unit vs. local plant).

A significant determinant of how folks thought about this problem was how their ERP is implemented - in a fully integrated "enterprise" (Finance, Order Management, Supply Chain, etc.) - and/or how the instances are divided (all enterprise, by location (geography) or by business unit).

Note, however, that relatively few respondents are concerned with synchronizing data across multiple instances - a popular callout / feature of some MDM solutions. they will speak of "integration", but a focus of the conversations were all around quality and process, not synchronization.

An interesting frustration from some of the respondees; the ERP system(s) do not capture all of the required attributes for an item, so these additional details are kept in a separate, siloed system. Easy examples would be specific attributes (like shipping material specifications), but there were multiple instances where [so-called] Master Data is calculated with complex formulas / rationale, so an Excel component is required (typically in the area of pricing / quoting details).


Size & Scope of Master Data

Predictably, there was a great variation in the responses - 100s to 1000s of customer, vendors, finished goods. However, the interesting trend was the notation that 10s of people (relatively large numbers, based on size of the company), were "responsible" (i.e. "did some of the data entry"). Could this be why there is interest in MDM and an MDM organization? Apparently, Master Data is often managed like a wiki - everybody is an editor.

Most organizations have no metrics in place; a few can speak to "data police", folks that actively monitor the data looking for issues. Best examples cited included "Health Check measures" (does data fit set of established guidelines / tolerances); vendor audits, and [results of] scrubbing (ex. Name And Address data against external sources).

When asked about the business benefits of a Master Data Management effort, most companies left this blank or said "none". I generally got the sense that hard benefits are difficult to quantify; notable exceptions seem to come from past pain. Some organizations spoke to inventory reductions and transportation savings - both derived from more accurate supply chain data, which is facilitated by clean, consistent, complete Master Data.

Master Data in the Organization

Many companies keep control / accountability at the functional area. However, companies with "enterprise ERP" implementations (full integration of Finance, Order Management, Supply Chain) typically call out ownership at the Enterprise level. It's not about the size of the company or the recency of their implementation - it's the degree of integration within the primary ERP.

Organizational specifics were tougher to get at - depending on how the company managed their master data. Generally speaking, companies that manage Master Data at a functional level (Customer Service, Purchasing, Finance) have organizational clarity. However, folks that say they manage at the Enterprise level had the wispier definitions for Title and Accountability

Of note: centralized MDM teams rarely manage the bigger projects (implementations, acquisitions, or special projects with large MD components) - but they will (out of necessity) participate. None of the respondents look to these organizations / people for project management skills. However, there were some good callouts for the communication / change management skills required for the role, especially where the group has to review implications of adds / updates [of Master Data items] with multiple groups that will/may be impacted.

Scope of Responsibilities

An interesting, consistent set of answers in this area; "Yes, we take ownership and accountability - but no, we can't measure it". To be fair, not all companies had that clarity of ownership, but the lack of sharp, clear quality metrics is noticeable. Content, Quality, and Governance are consistent in all of these companies … consistently not-well defined, not well measured.

Positives & Challenges

Funny how best practices in one company are challenges in another. There are two recurring themes throughout the responses; Quality and Complexity. The latter is interesting; this was the first point in the survey where the difficulties of Finished Goods Master Data were raised. Many companies call it out as a large challenge; all of them cite the complexity, the multiple facets (manufacturing, packaging, warehousing, transportation, pricing, costing) and the cross-functional nature

Full Results

The summary results document is available for download from here; I will add a version date on the page and keep it up to date as additional surveys come in.

Questions? Comments? Suggestions? Let me know ...

Previously ...

• 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)
• Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
• The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
• Who owns Master Data in your company? (May 30, 2009)
• Bootstrap Market Research: Master Data Management (What, Who, How) (November 30, 2009)

Technorati Tags: best practice, collaboration, CRM, documentation, ERP, hands on, Knowledge Management, SAP, supply chain, tech management, wiki

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

As the new year approaches, debates over the "value" of IT and business projects intensify; it's not holiday stress, but the excitement of the approaching New [fiscal] Year. Lately, I'm hearing more about the struggle to quantify business value, especially when selecting those few projects that will "make the cut". We will definitely iterate on our scoring framework, adding a cost / benefit template to facilitate more apples-to-apples comparisons between projects (yes, don't scoff  - it is possible - more in a later post ...)

However, I think there's an interesting vision in some people's minds; a sort of value-optimization Utopia where, even with hundreds of project ideas on the list, the executive team has the insight and ability to select the best projects and fund them appropriately -  as long as they all have business values assigned.

I don't think assigning a value to every proposal is realistic, and certainly not something to aspire to - well, not directly anyway. There are a number of significant hurdles to deal with - the reluctance of people to commit to hard benefits, the lack of suitable productivity metrics for new technologies and methods, and the difficulty of communicating innovations to those who didn't think it up on their own (ie. close the patent office, we're done).

Yet, even if you did address all of those problems, and could easily measure impact and communicate effectiveness on 300+ terrific project ideas - how could anyone to claim the ability (or the time!) to rank such a list from "best" to "worst" (or, since I don't propose projects are bad to begin with - "most best" to "least best")? Truth is, they don't - most of the business leaders I've worked with have no interest in looking at 300 projects, and would be a tad perturbed if I tried to get them to peruse such a list. Do you appreciate it when your teams bring a thousand problems for you to sort through?

Rules of Thumb

Most people have a favorite way of eating their elephants. Yes, one bite at a time - but where to start? How to carve?

Deliver Small, Iterate, and Evolve: The agile among us would focus on short-term deliverables with small measurable steps to make incremental improvements. Speed and iterations will drive the quality and help focus on those areas of work that have the most short-term promise.

Focus on the Big Rocks:  The biggest and toughest problems - or the projects with the most benefit - are sometimes so daunting that they intimidate us into dealing with "the easy stuff". Clear your calendar and tackle these larger opportunities first, else you'll never get to them.

Focus on the Constraints: Understand which resources are keeping you from launching multiple projects at once. These are typically people - in key positions, with monopoly knowledge. Simplify things by prioritizing their projects first - but strongly consider launching efforts to remove the constraint, by having them document, train, or automate their knowledge.

Practical Problem Solving

As I proofread this post, it sounds like a checklist for common sense; no surprises, just a different level of detail depending on the organizational level you are speaking with. It's important to understand the fractal nature of business challenges; no matter where you stand in the organization, the number of items on your ToDo list (and/or the number of challenges you are juggling) is roughly the same. The sooner you can put yourself in the other person's shoes, and speak to them at the level of detail they (not you) need - the more effective your conversations will be.

Besides, they're paying you to solve problems, not define them.

Previously ...

• Measuring and Reporting IT Value (2 of 2) (November 20, 2007)
• Innovation That Matters - Substance Over Style (January 12, 2008)
• Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
• The Innovation Generation - Communication Styles (April 1, 2008)
• IT and the Business are Closer Than You Think (June 28, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• A Plea for Empathetic Communication (November 16, 2008)

Technorati Tags: business value of IT, documentation, innovation, Knowledge Management, people management, PMO, project management

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

New Collaboration Tools need Lead Time & Practice: Eight months ago, sharing files by e-mail and ad-hoc, unstructured meetings were the norm. To be fair, we were working smaller projects with teams of 10-20, and usually in no more than two locations. Over the past few months, as we were teeing up for Big Go-Live #1, we've been introducing the newer tools in small bits. For Go-Live Weekend, the team was already familiar with going to SharePoint for status updates, or recording a new Issue in the SharePoint list. The mechanics were old hat, and folks didn't need to think about it - which was nice, since we need them thinking about their Tasks. If we introduce new collaboration tools with little lead time before the Big Go-Live #2, Tasks will be interrupted with people struggling to remember how to communicate.

In the right setting, collaboration tools can clearly add value - even for the most conservative jaded technology users. However, you can't introduce something so new and expect people to "get it" in the short term. Better approach is to introduce the new tools early in the process, when there is no pressure. This lets the team build familiarity, understanding, and skills by the time you need to rely on these tools for critical communication.

Previously ...

• Dueling Collaboration Portals (November 23, 2008)
• Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
• Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
• Five Stages of Twitter Relevance (April 21, 2009)
• Over / Under Communication for Project Managers (June 29, 2009)
• Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: collaboration, entrepreneur, innovation, Knowledge Management, people management, project management, SAP, Social Networks, twitter, Web 2.0,

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

I once met with a rather thoughtful Project Manager to catch up on things. An interesting person to talk to – it’s the cadence and style of his chat, he's a fairly laid-back guy. I asked where his Stress comes from - he shows no visible signs of any, and it made me Ponder. We ended up talking about golf, IT Projects, and the “Search for Perfection” in our work.

So, what is “perfection” in the IT world? Is it being able to predict what will come true, and then everything hits as you foretold? Or does it appear when the programming / configuration / cabling is done, and everything does exactly what it was supposed to do?

Consider time-boxed (or agile) projects versus the traditional waterfall style. Is “perfect” acheived by hitting the date (but not getting all the requirements), or should we value delivery of all of the requirements (but not in the originally estimated time)?

Back in the day, we would work to write code that compiled “perfectly” - no severity level 20’s or 10’s, as we used to say in RPG.

What about fault tolerance, scalability, or quality of testing? These "requirements" deliver business value when [bad] things fail to happen (some tao to jones on). Note that these also become bargaining chips when time is tight … ephemera less valuable than squeezing in one last combo box.

Obviously there's no right answer, but my calm PM friend and I feel that one’s definition of “perfect” says a lot about whether or not you experience stress at work; this is when the conversation switched to golf.

Why do we both like Pasture Pool? Neither of us are competitive by nature; it’s more of a way to search for perfection (or burn an afternoon, or get some bidness done). And the interesting part is, it could be this never-ending search …

Where do you go when you can par your favorite course – for a lower score, or the next course to the left?

According to the zen PM, “if I’m a 15 handicapper, I could get down to 20 handicapper with more practice” [ok, he clearly plays more than I do], which led me to ask what exactly is a “perfect score” – is it par golf? zenPM suggested that a perfect score would be birdie every hole; I thought perfection could be when you hit every fairway and green in regulation, and you're down in two.

So is perfection “peak performance” [on time], “consistency and predictability” [on budget], or “strictly following the rules” [no 10’s]?

Then we had to get to our next meeting … back to the stress …

Previously ...

• How to Cheat at the PMO Prioritization Game (December 14, 2007)
• Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
• Rules of Golf - Project Prioritization Process Needs Clear Documentation (February 18, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)
• News for Wombats: Taming Unreasonable Requirements (January 26, 2009)
• Failing Faster (June 14, 2009)

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

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

Introducing buzzword-compliant technology like a wiki, or integrated collaboration spaces like SharePoint, will typically go well with a motivated audience like your internal IT department. But if you really want to understand how this stuff works, try it with "real people" - line employees in sales and marketing, operations, and finance.

Sure, you've heard complaints from these folks (they have better PCs at home, the SAP/Oracle UI is brutal compared to Amazon and AT&T U-Verse, and why can't they just connect their new iPhone to the corporate mail server?). Be warned; demanding users are not necessarily technically savvy when it comes to groupware.

Case in point; we are working a rather large project (many months in length, over 100 people throughout the business) using SharePoint as our collaboration space - and learning an awful lot about what we thought we understood about ease-of-use and intuitive user interfaces. Our collaboration space is a basic SharePoint project site, featuring the usual suspects - a Shared Document library, an Issues list, and an Announcements section. Simple right? Well, maybe not ...

Documents Check In, but they Don't Check Out

Just kidding, the actual check-in / check-out mechanism works fine. It's just very interesting that this basic concept of version control is lost on most end-users.

But let's start with the document library itself - it looks like a really nice version of File Explorer, but becomes very frustrating to folks when they try basic tasks like drag-and-drop. Yes, we found the simple solution - there is an option to open the folder in Windows Explorer, but since this menu option is buried right above the file list, it's hard to find - certainly not "intuitively obvious".

Version control was a difficult thing to explain - thank goodness for the tight integration with Office 2007. We found it easier to show folks how to edit documents with a simple double-click - that works just like their shared folders on the old file server! You can explain the concepts of version control quite easily, but the whole check-in / check-out, keep-a-copy-on-your-local-drive thing just gets too complicated. We did have to deal with the one-time task of checking in a new document after you upload it, but after that, they just open the files directly, and that's it.

There is one feature of Shared Document libraries that I really like - the ability to add custom attributes to documents that can appear as columns in the view. Makes it easier to sort / select / search on documents, and people "get it" relatively quickly. Just go easy on the version control.

... Here's a SharePoint Tissue

I think the most powerful and elegant feature of SharePoint is the flexibility you have with basic list management - even with WSS. Truly, this stuff should cover over half of the "fancy" automation tasks that folks are are asking for. However, I'm still surprised / dismayed by the fact that SharePoint doesn't include a standard graphical indicator - you know, the classic "stoplight" (green is good, yellow warning, red means um, er...). I've written about this one before - why can't I have a simple datatype (vs. putting together a sneaky little script to make it work).

I also have a significant warning / insight about trying to do too much with your Lists. Do you realize that most end-users in a typical SMB have older CRTs? I'll bet you still have a large number of 15" CRTs with slightly foggy tubes, on their last legs (but too expensive to change out for all but the executive staff) (ok, and IT too, sorry). In addition - well, let's just say that I'm not the only one whose eyesight is beginning to fail them; I can't tell you how often I've tried to talk folks into moving their screen resolution higher than 800x600 - but it just doesn't work.

What's my point? Before you put too many columns in your Lists, or too many gadgets on your Site, check with the average user to make sure that it looks okay on their Screen. Heck, before you even begin your design, use SMS or a simple script to poll the user community and find out what kind of screen resolutions have been set. Catering to the lowest common denominator is not a cop-out, especially when the point of a collaboration site is to get people to actually participate!

Push vs. Pull Messaging

(Another opinion:) I think most powerful aspect of collaboration sites is the aggregation of all knowledge about a project into a single, searchable repository. When people send project updates or resolve issues / hold discussions over e-mail, all that knowledge is buried and quickly lost inside people's inboxes. In SharePoint, a typical Announcements web part (yes, I know it's just another kind of List) is quite practical as a messaging medium, because folks can sign up for e-mail alerts.

Don't underestimate the attraction of the e-mail. People are used to getting information delivered to them in their inboxes - it's expected! All I'm saying with my Announcements list is that you have to subscribe to the information and pull it towards yourself (versus expecting me, the project manager, to remember to push it to you - and everybody else that might be interested).

Real-world learning: this concept didn't take long to grab hold in our project. It makes sense, people understand it relatively quickly.

On The Good Side

Don't get me wrong, there is lots of good that's going on. Now that the larger project is getting used to this new collaboration space ...

• ... our issue tracking list gets better every time someone touches it - and now we have consistent consolidated issue lists for all aspects of the project
• ... we are advancing our state-of-the-art for shared authorship; there is a lot more visibility to who is working on what, and we're getting more participation than a normal project
• ... the combination of all these different pieces - shared documents, issues, announcements, and other things - are massively facilitating communication, and it is noticed by the folks on the team

Yes - these collaboration tools will definitely will bring huge value and streamline communications to your project. Just don't think it's easy or obvious.

Previously ...

• Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
• 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)
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
• The Innovation Generation and User Interfaces (April 9, 2008)
• The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
• Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Is SharePoint WSS dangerous to SharePoint contractors? (February 4, 2009)
• Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)

Technorati Tags: collaboration, hands on, Knowledge Management, people management, PMO, project management, technology, Web 2.0, wiki,

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

Commiserating a week or so ago with an old friend, struggling mightily with some external consulting firm providing technology talent, developing customer management systems for Big Sales Company. There were some critical dependencies on the server side, and the (internal) project team needed some on-site assistance working through the issues. Ad hoc phone support was just not cutting it - but the external project lead was pushing back. It's very difficult to get on-site, dedicated help for these in-demand DB technicians with little advance notice. My friend would have to wait a few weeks - which did not sit well, hence the commiserating.

Of course, I could easily see his counterpart at the consulting firm venting over his own frosty mug; I myself would feel ill-used (to some extent), because it’s not really reasonable for Big Sales Company to ask for something immediate like this – you just don’t turn these people on and off like a faucet.

I [politely] note that my friend is not the greatest at diplomacy, especially when dealing in shades of gray. He gets too specific, too black-and-white with his thinking; I really don’t think he’s empathizing with the components / teams he needs to work with to get the projects done. They are the subcontractor, the subordinate - he just wants to tell them what he needs, and expects them to hop-to and get stuff done. Don't define problems, define solutions, yada yada.

That’s not always the most effective way of dealing with the situation; it helps a lot if you can empathize some with the subcontractors / subordinate / supporting teams’ world. Understand the tasks you are asking them to do - so you know when they are sandbagging, but can appreciate when they are committing to getting some really significant stuff done. Don’t just tell people what to do – work together, in a partnership.

But then, as I said this, it occurred to me that this was all just a reflection of how this person manages up when working with the business. Ok, he's a bit older than me, so after all is said and done, he still thinks the business can ask for anything, can put any wacky requirements out there - and IT just has to figure out how to get it done. Of course, what's good for the goose is good for the external consultants - the frustration stems from the fact that the consulting firm is not behaving the way he thinks he would behave, if put in the same situation.

This is wrong on many fronts. IT needs to push back on unreasonable requests, if only to set the right expectations for what can happen. We need to help the business differentiate between what they want and what they need, to drill into root causes instead of fixing symptoms or papering over the tough issues.

The best PMs are good at managing up and down; pushing back (respectfully and constructively) on the project sponsors, and working with their supporting teams, not telling them what to do.

Previously ...

• PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
• How to Win at the PMO Prioritization Game (December 18, 2007)
• Don't Accept Snap Answers Too Quickly (July 6, 2008)
• The Power of Paper in Business Communications (October 22, 2008)
• A Plea for Empathetic Communication (November 16, 2008)
• PMO Nirvana is a Conversation, not a Schedule (February 22, 2009)
• Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)

Technorati Tags: collaboration, innovation, people management, PMO, project management, tech management, vendor management

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

It is often said that you can't over-communicate, but I'm willing to bet most folks - and especially your project sponsors - underestimate the cost and effort of this critical component of project management. Consider this fair warning - and a good checklist for folks wanting to get into IT, project, or functional management.

Media

To achieve any decent amount of success, you have to be a good communicator with both face-to-face and written / published media.

And by "good" I mean both "comfortable" and "effective". You should feel good in your own skin, confident that you can carry a conversation at all levels of an organization. And you also have to be an effective communicator - able to get your point across with the right amount of detail, not too much or too little. Another effectiveness challenge is the ability to balance between personalized, one-on-one written & oral communication, and insightful, understandable mass communication.

Translations

You may not realize how many different "languages" you speak - and effective managers must be reasonably fluent ...

• Languages - Finance, Operations, Sales & Marketing; business groups have just as many confusing specialty words as the techies in IT
• Dialects - Do you speak Oracle or SAPanese? Experienced in small companies or large corporations? Public vs. private? Entrepreneurial or slow growth? High volume low profit FERTs, or low volume, high margin custom products? The concepts are all the same, but sometimes the specific words are different.
• Slang - Slightly different than dialects - all companies, organizations have local shorthand term so that over the years in their particular organization to mean very specific, nuanced things.
• Sound Bites - A form of speech where a complicated topic is reduced to a single word or phrase. For example; ATP. Are we talking about master data, settings on time fences, the process of checking for availability, or the policies around A, B, C and D companies? Sound bites can sneak into conversations and you could be discoursing for 15 minutes before you realize you're talking about two vastly different things.
• Strata - Management v. line, Middle v. executive management. Depending on what level of the organization you're talking to, you will need to change the level of detail that you go into. Typically, higher up in the company means a lower level of detail that they want to wade through.
  

Change Management

Volumes have been written on this topic, but most people have trouble coming up with a concise definition of what this means. To oversimplify - but drive right to point: change management is typically about delivering "bad news".

However, "bad" can mean different things. It can be "disappointment": the date will slip, we're over budget, or we can't fit this feature request into the schedule. However, adjusting expectations as early as possible is one of the basic skills of a good project manager. You need to be willing to deliver bad news like this as early as possible.

The other significant area of "bad" - walking into an organization, a group of people, or a individual's cube, and letting them know that the way they have been doing things for years is about to change. Sure, it's easy to say that "change is hard" and "change is inevitable", but you yourself probably don't like change in your established rituals. Empathy is the key here.

Lessons Learned

As with many other things, the more project communication you do, the better you get. Some of the more common lessons learned:

• Defensive project teams will often negotiate for delay by asking for / waiting for More Communication, and complaining about Not Enough Communication
• In any project plan, you will underestimate the time required for communication, the number of times you'll have to repeat the message, and the ability of the team to consume your communication in various forms of delivery media
• You will definitely underestimate the time required for follow-up and follow-through to make sure it's Done
• You will overestimate the amount and quality of existing documentation, and the ability of the project team to bridge the gap to the required level of documentation

Here's the killer -

• If you try explaining to management about the problems / challenges of communication, they won't listen and/or won't understand (yes, that is a tight loop)

Machines will never replace us - but this is one case where sometimes, you might wish they could.

Previously ...

• Communicating Complex Technical Concepts (March 21, 2005)
• Euphemisms, and a career-extending paradox (July 11, 2005)
• Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
• Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
• War Stories from the Change Management front (August 21, 2006)
• Communication is the responsibility of ... (August 19, 2007)
• The Five Fundamental Rules of Project Management (October 15, 2007)
• Butting In to the Conversation: PM Communication Tools (February 26, 2008)
• There ain't much IT in IT Management (May 7, 2008)
• Can you, should you, bother Executives with The Details? (May 30, 2008)
• More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions) (June 12, 2008)
• The Power of Paper in Business Communications (October 22, 2008)
• A Plea for Empathetic Communication (November 16, 2008)
• I Think I'm Learning SAPanese ... (November 22, 2008)

Technorati Tags: communication, documentation, Knowledge Management, people management, PMO, project management, tech management,

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