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 ...
Managing Change: Knowing, Understanding, Empathizing
Do you
know your job, or do you really
understand your job? One difficult part of change is getting people to see the difference.
Of course, this is seriously delicate stuff - you can't just walk in and ask people if they understand what they are doing. You know you'd be insulted if someone asked you the same question. (Come on ... not just a little?) But think about it - how often have you had this conversation ...
" ... I look at the TPS Report every morning, and I look for something that is negative in this column. If the layout of the report changes, I can't do my job; you are gonna have to relayout this new version of the Report."
In other words ... I don't understand my job, I don't think on the job - I just respond to the stuff I am used to looking for.
The great unstated truth is that most folks don't understand what they do. They didn't implement it, they inherited it. They know the
how, but not the
why. Plus, human nature makes us avoid admitting our own ignorance.
As a result, resistance to change means resisting anything that upsets the As-Is. Unfortunately, the As-Is has a stealthy way of changing in little bits over time; that, and the fact that the folks who originated this particular process have probably moved on, taking their understanding with them. And so starts the slow, steady spiral to complete irrelevance, and slavish adherence to non-value adding work.
Empathy Helps Overcome EntropyTo make change happen in these environments, it helps to have - and demonstrate - empathy for how people feel and think, to lower the resistance and open the minds.
Show your self-knowledge, and humility, by freely admitting when your understanding falls short. As a team member - speak up! in public! when you don't understand the underlying process. As a manager - encourage folks to raise their hands and ask for help. And please - make it easy for me to seek help off-line, after the meeting ends, so I don't have to demonstrate my ignorance in public.
Realize, however, that there is a significant requirement to Get Things Done; we don't have time to stop and deconstruct everything. There is a significant business value in having a repeatable, lean process, and all of this 'search for understanding' is wasting daylight. Balance the importance of understanding with the need to get stuff done, by designing, documenting, and implementing lean processes with incremental improvements, that can drive results on day one, but can also mature and improve over time.
Set the expectation that Understanding the Job is just as important as Getting It Done - but don't forget that we are getting paid by our Results, not our Understanding.
Previously ...Technorati Tags: change management, collaboration, people management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: change management, collaboration, people management
Managing Change: Pick Something, and Do It Well
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,
Labels: business value of IT, change management, collaboration, communication, design, innovation, people management, project management
If I Told You a Fractal Solution, Could You Change the CEO's Mind?
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 ThumbMost 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 SolvingAs 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 ...Technorati Tags: business value of IT, documentation, innovation, Knowledge Management, people management, PMO, project management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: business value of IT, communication, documentation, innovation, Knowledge Management, people management, PMO, project management
Bootstrap Market Research: Master Data Management (What, Who, How)
I've been asked a lot of questions about "Master Data Management" over the past few weeks - what does it mean, who does it, and what are some tools and metrics that organizations are using to reign in this important aspect of ERP and analytics systems. I started reaching out to the folks in my professional network with some results, but I thought I might be able to leverage LinkedIn and Twitter to get input from far and wide. This "bootstrapped" market research might not deliver the depth and reach of the bigger technology research firms, but it will be interesting to see what can be gathered.
Bootstrap Market Research: Ground Rules
- I've put together a little survey (download from here) which is intended to take about 15 minutes to complete - that should give you an indication into the amount of rigor and depth I am looking for.
- Please fill it out and email the result to BMRMDM@cazh1.com
- I'm trying to get input from a number of companies - large and small, with all sorts of ERP systems. So in return for your input, I'll be happy to email you an aggregated, anonymized summary of what folks are telling me. Please note that none of your specific answers will be tied to your company name in any way.
Some Definitions
What do I mean by master data? Compare and contrast to transactions ...
- Transactional Data – describes “events”
- Production orders, material movements, and confirmations
- Customer orders, shipments, and invoices
- Payments, credits, rebates, and returns
- Journal entries
- Master Data – describes “facts”
- Finished goods, raw materials, and work-in-process
- Manufacturing routings, warehouse picking strategies
- Customers, vendors, employees
- Organizations and hierarchies
- Chart of accounts
- (also referred to as Reference Data, Configuration Data)
The Question of Ownership
I've asked this question before – who owns Master Data? – but there may be some different understanding over what “ownership” refers to. Is the "owner" responsible for …
- Master Data Quality?
- Data Structure, including requirements and interdependencies
- Process & Procedure for getting Master Data into the system
- Access & Training for getting Master Data out of the system
- Audits & Quality Checks to make sure corporate requirements and standards are met
- Metrics & Visibility for critical Master Data processes, especially when adding new products
- Master Data Content? (for example …)
- Structure of the chart of accounts
- Bin configuration and capacity
- Modeling manufacturing processes in a routing
- Product families, sales org hierarchies
- Credit ratings
- Material substitution
Benchmarking Survey Questions
The survey asks some high level questions in these areas:
- Master Data Definitions
- Size & Scope of Master Data
- Organization Structures
- Scope of Responsibilities
- Positives
- Challenges
There is also space at the end to bounce back some questions - let me know what else is on your mind!
AtDhVaAnNkCsE
Thanks (in advance) for your input - and watch this space for the results!
Previously ...
Technorati Tags: application, best practice, collaboration, operations, supply chain, tech management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: collaboration, design, Knowledge Management, LinkedIn, people management, supply chain, tech management, twitter
A Company is like a Sphere
Where do these great analogy ideas come from? Full credit - I got this one from a speaker at the
SAP Research Center in Palo Alto, last spring.
A company is like a sphere. As it grows, volume increases much faster than surface area, and the large a company gets, way more people get embedded and hidden from the end customer than are on the fringe, in customer-facing roles.
As a general rule, this is a bad thing. Well, maybe a less-than-optimal thing - what percentage of your corporate attention span is customer-focused?
Our Challenge is to poke some pockets into the surface, and get more surface area exposed to the outside air.
- Will this help a company go farther? It seems to work for golf balls ...
- Will this make the company more human? Perhaps, in a self-fulfilling / reverse fractal kind of way ...
- Will rough edges generate incremental profit? Some counterintuitive friction ...
Previously ...Technorati Tags: business value of IT, CRM, entrepreneur, innovation, Knowledge Management, marketing, people management, SAP, Social Networks, Web 2.0
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: business value of IT, collaboration, communication, innovation, Knowledge Management, people management, SAP, Social Networks
Perfect IT
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 ...Technorati Tags: business value of IT, collaboration, people management, project management, tech management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: application development, collaboration, communication, generational diversity, innovation, Knowledge Management, people management, project management
Real Business Users and SharePoint
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 OutJust 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 TissueI 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 SideDon'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,
Labels: collaboration, communication, design, documentation, hands on, Knowledge Management, people management, PMO, project management, SharePoint, Social Networks, tech management, technology, Web 2.0, wiki
The Delicate Art of Pushing Back
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 ...
Technorati Tags:
collaboration, innovation, people management, PMO, project management, tech management, vendor management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: collaboration, innovation, people management, PMO, project management, tech management, vendor management
Over / Under Communication for Project Managers
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.
MediaTo 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.
TranslationsYou 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 ManagementVolumes 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 LearnedAs 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,
Labels: communication, documentation, Knowledge Management, people management, PMO, project management, tech management
Failing Faster
Here is a simple question to ask yourself: do I insist on solving problems myself? A noble goal, until it takes too long to get the answer. Why don't we fail fast enough to ask the question to someone who knows? Remember, we pay a ton of money for annual maintenance to our enterprise software providers, so we should [more quickly] be "giving up", and submitting the question to the "experts" to get to answers quickly.
In an earlier post, I asked Would you like me to Google that for you?, which is kind of a sideways slam - IT people can and should be able to get questions answered on their own. So, why is it that some folks search Google or consult other experts, and get their questions answered quickly - versus insisting on figuring things out for themselves? My personal theory is that they're not "lazy" enough; I've got many other things to do, so I want to find a quick way to answer those questions. (Note that laziness also makes me want to find the good, solid solution and not the quick-and-dirty one, because I don't want to have to come back later - I'm proactively lazy.)
It possibly has something to do with maintaining face in front of your manager ("I think someone expects me to figure this out …"). Corporate culture may tend towards a desire to get something "done to quality"; I have to get 100% of my requirements into the finished project, and if it takes a long time - so be it. Or, it could just be that you are lost in the problem, and are not aware that time is flying and nothing is happening.
It may take a bit of humility, but the truth is often more humbling - folks don't care if you solve the problem, they just want the problem solved.
However, it is also true that when the dust settles, people will remember that you got the problem resolved - method is less important than results.
Previously ...
Technorati Tags: collaboration, design, development,
people management, productivity, project management, tech management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: collaboration, development, Knowledge Management, people management, tech management
Who owns Master Data in your company?
I've had to respond to this question, inside and outside of the company, in a number of different conversations over the past few days. It's interesting, because this is one of those conversations where
semantics mean a lot - what people say is just as important as what people don't say. I only mean that people assume their listeners have precisely the same understanding of the concepts - which is often a mistake.
Case in point - who owns the
Master Data? It seems obvious to many IT folks, having dealt with ERP and data warehousing in the past, that the business owns the Master Data - it's their business, right? Then why so often does the business look to IT to take the lead on cleansing / populating / defining / loading Master Data?
Business owns the Master Data... they make the decisions on specifics. What should the next item number be? How should we structure the routings? Who defines the standards for bin / storage location / building / plant / campus identifiers? What is the desired format for capturing customer street addresses consistently? How will we set up the chart of accounts?
The business knows that
who and the
why of Master Data.
On the other hand, and in most companies ...
IT pwns the Master DataYes that is the correct spelling. For those who don't know, it’s a hacker term; when I
pwn the system, I have a root, I have a system admin access. I understand the technical underpinnings and details - I know how everything fits together. I know how to do anything I want with the system.
In Master Data terms - IT understands the data architecture and the interdependencies. They know all the transactions required to enter data into the system, and what security roles are in place to limit access to those transactions. IT also has tools and knowledge on how to extract data from the database and batch import data en masse.
IT knows the
what,
when, and
how of Master Data.
What does that mean?When an organization needs to get its Master Data in shape, it's going to be a team effort between business and IT. The business must take the lead, making and clarifying decisions and driving the details. But IT absolutely needs to be right by their side, helping with the mechanics.
Previously ...- Putting Data into Context (February 28, 2005)
- Bug bad, bug good, bug Bug (May 18, 2005)
- Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
- Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
- War Stories from the Change Management front (August 21, 2006)
- I Think I'm Learning SAPanese ... (November 22, 2008)
- Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
Technorati Tags: best practice, design, people management, project management, SAP, tech management,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: application development, collaboration, documentation, Knowledge Management, people management, SAP, tech management
A Plea for Empathetic Communication
It's impossible to over-communicate
Sounds a bit strong, but if you think through your real-world experiences, this shouldn't surprise anyone. No matter how hard you try, your message will be missed by someone ...
Problem: It's all their fault!
Rely on Web 2.0, and ...
- ... they won't subscribe to the RSS feed; they don't understand the concept, and have no other information sources that supply feeds
- ... they won't sign up for the email notifications; that feature is hidden, no one told them about it
- ... they won't read / browse / search the wiki; there are too many unfinished pages in there, and they don't consider it reliable
- ... they can't find it using intranet search - they don't know where this feature is located. And even if they did, the results aren't as targeted and "right-on" as Google
So, you try to rely on "first generation" electronic media, but ...
- ... they didn't read the email, it got lost in their inbox with 100 other new messages today
- ... they didn't see, therefore, didn't read the attachment
- ... they did not check their voice mail
Even the "old fasioned way" doesn't always work ...
- You are having a face to face conversation, but it's not sinking in because they are checking their Blackberry and thinking about the currently unfolding interruption ...
Solution: Don't jump on the latest communication bandwagon and expect a
Silver Bullet - you need to balance flexibility and focus. Different media work for different people, so work to communicate your message using a variety of methods. Of course, if you try to supply all media for all tastes, there won't be enough time to get any real work done. Just know that there is no one best way to get information out to all who need to hear your message - and adjust accordingly.
Problem: It's all your fault!
If you can get them to the electronic content, you still have to create content that actually communicates the correct information. Even if they are capable of subscribing to RSS feeds, or opening a document attachment - if the content does not convey with clarity, they won't catch your drift. Worse yet - if the first one or two samples don't convey
anything, they will stop listening to
everything.
Solution #1: Practice practice practice - The only way to get better at anything is to keep iterating.
Observation: It's no one's fault - it just is ...
Think about it - don't you receive messages in your inbox that are not clear / difficult to read, or hear about things after the fact or through the grapevine? And don't
you glance at your Blackberry during meetings? When you set your phone to vibrate, you avoid distracting others (good!) but you are invariably distracting yourself (who just called ....?)
Fact is, we are all swimming in a sea of information, bombarded with messages from all sides - and we're bombarding others as well. A little humility and a lot of empahty go a long way ...
- Get feedback - if your medium or your content are not effective, find out why. Ask your intended audience what works best for them. Majority rules, so if you have a few email holdouts that don't know how to set up an RSS reader, do it for them. Better yet, do it with them - and show them what else they can subscribe to!
- Understand what the current corporate / organizational / local culture is, and play to that. You don't have to accept the status quo - but don't tilt at windmills just because wiki is a cool sounding word that would look good on your resume. Introduce change judiciously, and don't let it override the goal at hand - you need to get the status of this project updated!
- Never undrestimate the power of face time. When you craft a beautiful, concise, complete summary of the upcoming meeting, and someone still insists on calling you up and talking about it - don't look on this with disdain - it's an opportunity! What was it about the email / document that was incomplete? Was I not clear? Also, since most recipients of project updates are getting them for a reason (stakeholders!!), it's a great opportunity to make sure they get the big picture, understand the original objectives, and are still in support of the initiative.
- Projects end, but relationshps go on. It's always good practice to improve your communications and connections with the various technology and business process teams, in and out of the company. These is always a "next time", and next time could be that much easier if you are consistently building your foundation of clarity, openness, completeness.
Effective communication is very difficult, and requires constant work. Realize this, model your actions accordingly, and your impact and influence will grow.
Previously ...- I have nothing to say and I am saying it and that is poetry (April 6, 2005)
- eMail on Blackberry Changes Definition of Acceptable eMail (September 19, 2005)
- Gee, this social network - presence - IM - knowledge management - collaboration stuff really works (September 25, 2005)
- 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)
- RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
- Opportunistic Insights from the RSS Stream (June 5, 2008)
Technorati Tags: blackberry, blog, documentation, Knowledge Management, people management, project management, Web 2.0, wiki,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: blog, documentation, Knowledge Management, people management, RSS, Web 2.0, wiki
Best Practices for Process Documentation: Iterations (2 of 3)
Last time, I wrote about
checklists, and showed the example of the
B-17 preflight. Simple, fits on a single page, and hits all the critical steps, in just the right amount of detail. Plenty of processes in the IT department are made That Much Better if they are accompanied by detailed, effective Process Documentation.
Of course, that's all
motherhood and apple pie - everyone agrees that the
existing checklists are great. But how do you get started? I mean, assuming you can
get the techs to agree to create documentation - how do you keep them motivated when they realize that the finished documentation will probably run to over 100 steps on multiple pages?
There's a really simple trick to make process documentation easy - and we'll steal it from the
Agile Development teams.
Time box your process documentation task; for example, you could schedule 1-2 hours before the work starts to develop some documentation (create or add to existing). Then get your work done ... and plan on another hour or two afterwards, making updates based on what you just experienced. Don't spend more than an hour or two - document what you can, then stop and get the work done.
You won't be finished, of course - but that's the beauty of electronic documentation and iterative development.
The first step of any process is always "make updates to the existing documentation". You only have to start with a blank sheet of paper once - the first time. Each time you go through the process, you update the documentation - it will only get better.
- A very complex, step-by-step procedure gets a bit more detailed with each iteration
- Examples, exceptions, and critical dependencies get called out after you "get bit" - and you never make the same mistake twice
- Lessons learned at the end may shift around the order of events - improving quality, speed, and minimizing downstream freak shows
After the first few iterations, you may find your changes, additions, improvements are getting pickier - but that's okay. I've
never seen a set of process instructions that couldn't be improved somehow ...
- Add checkboxes, page numbers, and space for follow up notes. Make the printed directions a working tool, a piece of paper that helps capture new learnings and process changes for next time.
- Add a spot to capture start/stop time or durations. Build up a history of time data - this makes it easier to estimate ETA, scheduling the event, lining up resources, etc.
- Rework the process document to function better on your corporate intranet - eliminate the need to print and distribute.
- When vendors introduce new versions of software, new features to implement, you'll be ready to incorporate those changes into your documen.
The key is to never think of the document as Finished. Don't fall into the trap of skipping the Process Review step, before AND after you perform the tasks. Once you stop, it will be hard to get back into the habit; process entropy sets in, and before you know it, you are back where you started - undocumented, out-of-control processes.
Previously ... Technorati Tags: best practice, business value of IT, collaboration, documentation, Knowledge Management, operations, tech management,
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: business value of IT, collaboration, documentation, hands on, Knowledge Management, people management, tech management
Facilitating Innovation: Establishing an Environment of Possibilities
Facilitating Innovation: Establishing an Environment of Possibilities
I'm exchanging email with someone interested in establishing a skunk works, and they are asking some very interesting questions about the nature of innovation and the ingredients for an "environment of possibilities" ...
... things are ... [as they are] because someone already tried unsuccessful alternatives ... [This] begs the question: when it is required, how can rapid innovation be achieved?
Rapid innovation comes when the environment allows it and the skill sets enable it.
- An "environment of possibility" just means that folks are given some time to experiment with new technology, and access to the resources required to play around a bit.
Caveat: The challenge, of course, is that many folks expect the employer to allocate x% of their 40 hour work week, and provide training classes and server space to mess around with. Invest a little personal time and capital - in IT, it doesn't take much to build a solid development / test environment and start teaching yourself!
- I believe that the "innovation skills" are in everybody. But just like any other activity, success is 10% inspiration and 90% perspiration - individuals / teams / organizations need to build their innovation muscles by doing.
Caveat: A critical requirement for this piece is has to be ok to fail. The corporate culture must expect a failure rate for new ideas - remember, if it was easy, we'd probably already have thought of it!
... I value both history and future opportunity and am seeking a balance. Is this the same in your experience?
Well, Santayana was right - "those who do not remember the past are doomed to repeat it". But history should tell you specifically what tactics to avoid, but not necessarily what strategies will fail. Opportunity will be a mix of many things, and what was true at one time may no longer be true now. Look at imports from China - recent increases in transportation costs are making that strategy a loser for lower valued goods.
(and now, the "How-To Questions About Skunk Works")
Process: How does ... leadership successfully position a think tank or innovation team so that it is (a) buffered from mundane corporate operations and politics while (b) it remains sufficiently connected to executive leadership and operating divisions for its ideas to be acted upon? (I'm assuming that the skunk works is outside the normal corporate business structure.)
Ah, this is an incredibly important question. Skills and environment aside, I've seen successful innovation happen only when the team was sufficiently empowered to get ideas implemented. Sometimes this comes from executive sponsorship from just the right person - but not as often as folks think! The cynical or weak of heart prefer to wait until they are granted permission to work on a project or idea.
The "drivers" that get stuff done do so because they have all the rah rah stuff (vision, drive, energy, whatever), but they also typically have knowledge of how things work in a company. Sometimes this means a long-time employee, who has relationships with the folks that control the key people, resources, and decisions. Sometimes this means the uber-techie who already knows how the various pieces of process and technology work, so they know how to call out the resistors when obstacles are thrown in the way (no budget! no approvals! too difficult! systems can't do that! it's against policy! yada ...). And you don't have to be a long-term member of the organization to be successful; experiences from multiple industries, organization, technologies, etc. can all be applied by someone with imagination and drive.
So, leadership needs to stack the deck for their innovation team by ...
- Carving out time in their schedules; don't just add this to everything else on their plate - take something off!
- Provide visible executive sponsorship. You need to be able to pull that card out every once in a while (You need to make this change because the CEO said so ...) - not often, but now and again ...
- Staff the team with a mix of long-term and newer employees
- Identify a team leader that has the right mix of hands-on technical (this cannot be a administrative role only - they have to be able to do something!), business, and relationship-building skills. They must be able to spot the opportunity through the hype, understand how it translates to business value, and then communicate that effectively and concisely to those who need to support it
- Hold their feet to the fire - the team should have goals and objectives, it's not a license to play!
- Let them fail! The most successful baseball players fail 70% of the time!
Also, the skunk works must remain connected to operations - they'll have to implement the "big ideas" eventually, and it's always good to remain grounded in reality. Make participation on the team a part-time thing for most; consider rotating different people in from various areas of the company, so everyone has a chance and all remain connected to the base business.
What lessons have you learned from the skunk works experience that you can apply to the innovation process? What broad, meta-issues and narrower specific issues has your project illuminated and solved (or at least, what questions has it posed)?
Aside from the organizational and change issues mentioned previously, I have found that innovation efforts often target things that are perceived as issues, but they are actually symptoms of more fundamental behavioral or structural problems. Web 2.0 tools and techniques are often lauded as new ways to unlock the wisdom of the crowds, connect with the new work force, or counter the flight of knowledge leaving the company upon retirement. Unfortunately, some of these efforts struggle due to what I call the Law of Large Numbers, which basically says that what works on the Internet doesn't always work at a corporation.
Also, it always seems to boil down to "Change Management" - an overused buzzphrase that just says change is hard (especially from a vending machine). There are many ways to address this (education, repetition, participation), but management always needs to understand that corporate operating processes typically don't catch on like consumer products - here today, gone tomorrow (look how fast the Apple iPhone turned over a new version!)
Previously ...
- Motivating Maintenance Programmers (January 6, 2005)
- Moving to Eclipse Ia - Relevance (June 1, 2005)
- Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
- My Favorite Paradox (August 13, 2005)
- Subtle Anarchy (August 22, 2005)
- The "Army Rangers" model for IT Professionals (January 2, 2006)
- Guidelines for Success with your Skunk Works project (June 19, 2006)
- Innovation That Matters - Substance Over Style (January 12, 2008)
Technorati Tags:
design,
development,
entrepreneur,
innovation,
operations,
people management,
tech management
Invisible Technorati Tags:
cazh1,
FEI,
Front End of Innovation,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: application development, design, development, entrepreneur, innovation, people management, productivity, project management, tech management
IT and the Business are Closer Than You Think
IT and the Business are Closer Than You Think
A few passing observations from the last few months; contrary to what many (IT/business) folks believe, they are just as good or just as bad in managing processes and projects as their counterparts in (business/IT).
Problem Resolution is Everybody's Problem
A few weeks ago I was discussing issues that came up with one of our systems, and the team was a bit dismayed that the user community was still finding errors (we should be trapping for that stuff!) I pointed out that it's illogical to worry about stuff like this. We've implemented fault-tolerant systems that predict as many problem situations as we can think of, with lots of alerts and doublechecking built-in. If we can think of a problem, we will build a trap for it. It stands to reason, therefore, that the only bugs to appear are the ones that we couldn't anticipate - so the only people that will experience the bugs will be the people using the system.
It's inevitable that end users will find your problems, and that's nothing to be concerned about - we're all testers, and testing never really ends (in a continuous improvement environment). What you should be concerned about - how quickly we can turn around a fix for the problem? What is our total uptime? Do we see decreasing numbers of new problems, and zero recurrence of previously reported problems?
Truth be told, the onus of root cause is just as much on the business. Was this a scenario that could have been predicted? Were the requirements amd/or testing scenarios complete? (... apparently not ...) When projects are well run, and it's a true partnership between IT and the business, misses like these are everyone's problem.
Nature Abhors a Vacuum
Business managers may not understand the details of the technology they work with, but they certainly understand good management techniques. Try working with any manufacturing operations group and not going to them with metrics or KPIs (Key Performance Indicators). This is their bread and butter; they cannot understand how anyone could manage without some form of metrics. And if they see none, they will not only notice the problems, but will proactively look for issues, assuming things aren't under control.
On the other hand, if you have a reasonable set of metrics and are managing to them, they certainly can't accuse you of not following sound management principles. They may provide feedback that the quality of their experience is still not the greatest - but a structured, metrics-driven approach shifts the conversation to towards a discussion about best metrics to manage to, and not whether or not IT knows what they are doing.
In the End, We're All [Bad] Programmers
Check out this article from CFO.com, detailing a number of "worst practices" that folks in finance to see their counterparts doing that make them cringe. Sound familiar?
- Poor Segregation of Data: Mixing critical values with complicated algorithms (business rules) makes for a delicate and hard-to-maintain spreadsheet (application).
- Poor Documentation of Assumptions: when revisiting (cloning/debugging) this report, if you can't remember the original assumptions (design), you may need to rework (refactor) the entire thing
- Poor Documentation of Constraints: complex worksheets with many simultaneous calculations would benefit from interim formulas in key cells (asserts) to test reasonable boundary conditions
- Difficulties in Making Changes: spreadsheets and formulas can and should be structured to allow for foreseeable extensions and modifications (subroutines)
- "Now It's Here; Now It's Not": at times it's too easy to change values in the worksheet to test different assumptions. And then lose track of all the changes made over time (version control)
- The Presentation Readiness Problem: when creating spreadsheets, analysts (programmers) should anticipate their use in final presentations (user interface)
In summary, the author provides this sage admonition ...
Treat the development of a spreadsheet - any spreadsheet - more like writing a term paper with footnotes and a bibliography.
See that? Accountants and programmers should aspire to be ... students?
Previously ...
- Heisenburg KM (July 13, 2004)
- Does IT make you productive (or, are you an existentialist or a fatalist)? (February 26, 2005)
- Things for the DIY programmer to consider (March 14, 2005)
- Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
- Sometimes analogies work amazingly well ... (July 14, 2005)
- Of course we can pay for that ... if it makes business sense (November 7, 2005)
- Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
- Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
- Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
- Stretching Your User Interface Design Muscles (April 16, 2008)
- There ain't much IT in IT Management (May 7, 2008)
Technorati Tags:
best practice,
business value of IT,
development,
documentation,
tech management
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: business value of IT, development, documentation, people management, tech management
