Sponsored Links

Online Chat

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

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

cazh1: on Business, Information, and Technology

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

Thursday, December 17, 2009

Bootstrap Market Research: Master Data Management (Results)

As previously noted, I've been doing a lot of discussion and data crunching around "Master Data Management" lately - so I've "bootstrapped" a little market research project. It's still a work in process - responses are trickling in - but I thought I might take some time to summarize what I am hearing to date. A document is available for download here ... the super summary follows below.

Survey Methodology

Please note: I am obviously not a professional market research firm, so this is is an understandably limited sample. Still, I am hearing some interesting things that may put your own Master Data work in a bit more context. 
  • 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'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).

Note: I believe we should consider computation of pricing as a (potentially) complex process that occurs in it's own transactional / analytical system (aka "the magic gonkulator"). The output is master data - but the calculations don't belong in an MD system.

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.

Note This is not always "out of control" - companies that have reasonably sized groups are the same ones that speak of metrics and controls. However, few report the existence of a centralized data governance organization (see below).

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

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

Invisible Technorati Tags: , , ,



Labels: , , , , , , , , , , , , ,

posted by James P. MacLennan at 9:11 PM | Permalink | 0 Comments

Monday, November 30, 2009

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
  1. 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.
  2. Please fill it out and email the result to BMRMDM@cazh1.com
  3. 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: , , , , ,

Invisible Technorati Tags: , , ,

Labels: , , , , , , ,

posted by James P. MacLennan at 9:08 PM | Permalink | 0 Comments

Tuesday, July 14, 2009

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

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

Invisible Technorati Tags: , , , ,



Labels: , , , , , , , , , , , , , ,

posted by James P. MacLennan at 10:22 PM | Permalink | 0 Comments

Sunday, July 05, 2009

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: , , , , , ,

Invisible Technorati Tags: , , ,

Labels: , , , , , ,

posted by James P. MacLennan at 6:33 PM | Permalink | 0 Comments

Monday, June 29, 2009

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.

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

Technorati Tags: , , , , , , ,

Invisible Technorati Tags:
, , , ,



Labels: , , , , , ,

posted by James P. MacLennan at 8:16 PM | Permalink | 0 Comments

Sunday, June 14, 2009

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: , , , , , ,

Invisible Technorati Tags: , , ,

Labels: , , , ,

posted by James P. MacLennan at 11:30 AM | Permalink | 0 Comments

Saturday, May 30, 2009

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 Data

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

Technorati Tags: , , , , , ,

Invisible Technorati Tags: , , ,

Labels: , , , , , ,

posted by James P. MacLennan at 3:14 PM | Permalink | 0 Comments

Saturday, March 14, 2009

Low Tech SharePoint Hack: Project Status Indicator

I'm doing a little hacking in SharePoint that is pulling together a few ideas from the past:
Apparently, I'm also trying to answer a question that is meaningful to many others, as it is used as an example in the Help files for Microsoft's online SharePoint guides, the add-on Web Parts we use here, and many other places. Why doesn't Microsoft make something like this a standard feature?

Note that I had some fairly specific requirements in mind for something that I would consider "low tech". this should be an approach that the average (read: non-IT) SharePoint site admin could use. I don't want to require third-party controls, nor do I want to require the use of SharePoint Designer. I'm also shying away from image files - little GIFs to show red, green, and yellow icons; I have established a style for displaying project status in that works great with PowerPoint and Excel, and I want to use the same images consistently on the collaboration space.

Of course, I wanted to get to a solution in a reasonable amount of time (ie. Speed to Value, or being proactively lazy). A few Google searches turned up a number of resources with different approaches. The best resource was this site, loaded with excellent SharePoint hacks - including one simple concept that requires me to tweak my ground rules, just a bit. To get this to work, I have to include a JavaScript routine on the page; however, I learned a nifty trick, one of those things that is fairly straightforward, but still has to be pointed out to you before you "get it".

The JavaScript Trick

You don't need SharePoint Designer to install JavaScript routines or special CSS on the page. All you need to do is install a Content Editor Web Part (CEWP) somewhere on the same page as your list. You can bring up the Source Editor and insert any scripts, you want, nothing will display about the routines will be available to the other controls / web parts on the same page. I'm not going to copy the code here - these guys deserve the web traffic for their work, so, go to this page to copy the script.

A Lot of HTML for a Little Indicator

The actual HTML for the "green" indicator (~) looks like this: .

Unfortunately the font changes based on which indicator you need - this table shows the various components for all of the status indicators.

StatusCodeFontColorResult
Green˜Wingdings 2green
YellowpWingdings 3#FFCC00
RednWingdings#DC143C
CompleteüWingdingsblack

My solution adds three calculated columns to the list. Why three? Well, yes, you could do the whole thing with one computed column, but the nested IF statements would be brutally complex, and I was hoping for something "self-documenting" (ie. clear and simple).

The SharePoint list in question is a typical Issue Tracker - and the first step is to define what the different statuses (statii?) are going to be. Here, I am only allowing Open (Red, Yellow, Green) and Closed - nothing like resolved or in process or proposed - we'tll keep it simple.

I then added three Calculated columns, and defined the formulas like this:
    Status_Char = IF([Issue Status]="Open - Green","˜",IF([Issue Status]="Open - Yellow","p",IF([Issue Status]="Open - Red","n","ü")))

    Status_Font = IF([Issue Status]="Open - Green","Wingdings 2",IF([Issue Status]="Open - Yellow","Wingdings 3",IF([Issue Status]="Open - Red","Wingdings","Wingdings")))

    Status_Color = IF ([Issue Status]="Open - Green","green",IF([Issue Status]="Open - Yellow","#FFCC00",IF([Issue Status]="Open - Red","#DC143C","black")))
I've tweaked the colors - standard yellow and red don't look good with a white background. (I burned at least 30 minutes fiddling with the color tones, to make something that was visibly yet subtle. Gotta know when to go fast and when to dither over the details ...).

Add a fourth column for the actual status indicator; we use the CONCATENATE function to build the HTML string as specified above. The surrounding <DIV> is used by our borrowed JavaScript function to signal the browser to turn this little bit into true HTML.
    Status_Color = CONCATENATE("<DIV><font size=4 color=",Status_Color," face='",Status_Font,"'>",Status_Char,"</font></DIV>")
Effectiveness Testing

Yes, this could have been done with a single calculated field - it's just a little bit easier to debug this way. In any event, it s a relatively large amount of code for a fairly simple effect - was it worth the effort? The ultimate test came when reviewing the list of open issues with the project team - and folks understood what was being communicated immediately. No explanation necessary - the conversation focused on the item marked "red" right away. If we just displayed the words "green", "yellow", or "red", it would take a bit more mental effort to understand what was being communicated. I really want folks to think about the solutions, and not waste brain power trying to understand the problems. A little extra effort in the code is just right.

Previously ....

Technorati Tags: , , , , , ,

Invisible Technorati Tags: , , ,



Labels: , , , , , ,

posted by James P. MacLennan at 3:06 PM | Permalink | 0 Comments

Sunday, February 22, 2009

PMO Nirvana is a Conversation, not a Schedule

We continue to iterate on our PMO processes - managing too few resources and too many project requests, an environment I have consistently seen in every IT group I have ever worked with. Our latest discussion concerned the concept of FIFO work on projects ...
    ... when presented with five things to do, I will only [emphasis added] work on them in the order received.
This is an exceedingly poor assumption for your personal run-rules, and a short-sighted objective for a PMO that needs to be aligned with the business.

You can't assume or aspire that your PMO can be a finite scheduler for IT. There is too much variability, softness, lack of clarity, process, etc. on most projects – especially at the Application Layer. Once you get anywhere close to business process and the fluid nature of business requirements, you have to have a strong element of agile, flexible resource scheduling and response.
    <aside> One might say that the lower you go in the seven-layer stack, you have a better chance of finite scheduling this stuff – projects can and should be more highly predictable, highly engineered. </aside>
Another bit of the conversation uncovered an interesting insight; is there "too much" communication overhead? The effort involved to document something completely, to build a detailed work plan, to create a detailed, multi-line resource forecast – yes, these all represent large chunks of work that do little to make something happen on the screen / in the database. However, the value of such effort is quite high, because the results facilitate complicated conversations in the future. It’s just like the idea of capturing requirements early on – saves tons of rework later.
    <aside> That last analogy begs a contrast to agile development - but agile values and requires focused communication and rapid iterations, which can be tough in an environment of thin resources and a high volume of "open" projects. Some elements of the classic waterfall are helpful when keeping multiple plates spinning. </aside>
A final quote - actually heard someone summarize the situation as "we just have a lot of slow projects". There are two important problems contained in that sentence - "a lot", and "slow". You have more control over quantity and duration than you may think ...

Previously ...

Technorati Tags: , , , ,


Invisible Technorati Tags:
,
,
,
,



Labels: , , , , , ,

posted by James P. MacLennan at 12:15 PM | Permalink | 0 Comments

Wednesday, February 18, 2009

Another Take on Enterprise Open Source

Today's best conversation was with Christopher Young, of B2BSX, a startup software exchange where corporate IT departments can buy and sell their development efforts, and make a little cash to offset stressed budgets. It's an interesting idea, and spawned some ideas in a couple of different directions.

Andy Hardy, IT Director

Every company I've worked for has toyed with the idea of selling some of their custom-developed stuff - well, every company except the first one, since it was a software development house (we weren't playing around). My "growing up" years as a developer have really jaded me on the idea of selling the deliverables from IT- or business-funded projects, typically for one simple reason - everyone underestimates technical support.

Operating systems change, DLL or JVM dependencies must be managed, and no one reads the manual - they all want support over the phone. Unfortunately, wide-eyed project sponsors or IT directors with dreams of P&L responsibility see COGS limited to the price of a CD, and revenues that match their ERP packages - it's not that simple.

Vertical Open Source

A solution, as presented by B2BSX, is to tweak the open source model a bit, offering source code for specific customizations, at low cost (well, much lower that building it yourself, I would assume). No long term warranties, no 1-800 support lines, you are on your own - but you are getting pre-built solutions that you can adapt into your own business, jump-starting your efforts with a basic shell, and adding your own refinements later.

I think of it as highly verticalized open source - sounds like they are limiting things to SAP right now, and I'd expect to see very specific solutions listed. By vertical, however, I'm thinking about reports / queries / wrappers that are very specific to a particular type of industry - the "long tail" of software niches, where most IT departments really do need to tweak that "collection of best practices" you were sold. I'm expecting to see stuff that is too specialized for a global software company to bother adding to their product.
    <aside> Maybe the "long tail" of ERP requirements is where the untapped value is for those guys ... </aside>
Custom Often Means Really Custom

Of course, there are still predictable hurdles for this model - not the least of which is the fact that this stuff is written by corporate IT. Hey, most of us have short deadlines and long backlogs, and little experience developing flexible software architected for iteration and flexibility. "Hard Coding" stuff is an academic Bad Thing that is often required to git 'er done (yes, I went there ...). Chris characterized this as software with tentacles, reaching all over your portfolio and gripping on tight - makes it tough to pull out and wrap into a nice package.

There may also be IP concerns - something to work carefully through with your legal department. Note: don't think that Legal has little to offer here, because every company should have some concern about IP and competitive advantage, even if you are not in the software industry. You should be maintaining control of your software IP when you customize COTS or contract work out - now might be the time to leverage it!

We're All from Missouri

I have no idea yet whether this exchange idea makes sense - but it could be just the time to look into this. We're all under budget pressures, and Mr. Young tells me that once you get the basic relationship set up, putting software out there takes very little effort.

Maybe this is where the real future of ERP is going. What if our maintenance fees kept increasing, but the acquisition costs plummeted - all the money is in the add-on services? The Xerox model, where you give away the copiers and sell toner and paper? Gives a whole new meaning to the term "copy protection" ...

Previously ...

Technorati Tags:
, , , , ,
, , ,

Invisible Technorati Tags: , , , ,



Labels: , , , , , , ,

posted by James P. MacLennan at 9:40 PM | Permalink | 0 Comments

Saturday, November 08, 2008

MS Project, Early and Often

99.9% of the project managers I know have at least heard of Microsoft Project (MSP), and all understand it to be a very capable, yet very complex environment for estimating and managing projects. But it's Saturday evening and I'm a bit cynical tonight, so I'll say that 50% of those people don't really understand how it works - and have many reasons why they should not use MSP for this project or that ...
  • ... this is an iterative development effort - not enough requirements to lay out a work plan ...
  • ... gantt charts are inherently waterfall, and this is an agile project ...
  • ... there are too many other things going on, and I can't (don't want to) model everything that these people are doing ...
  • ... this is a simple effort - small team, tiny deliverables - MSP is overkill (the phrase "shooting rabbits with a bazooka" comes to mind) ...
Cynicism aside, I think the last excuse is the most common; unfortunately, this sets up a no-win situation. If we only use MSP for large, complicated projects, when will we ever learn the basics? This negative line of thinking is sure to take you down an unfortunate path that ends in Excel task lists and endless emails looking for status updates. A better approach would be to see project management as it really is - not so tough once you learn the basics. (Add little to little and there will be a big pile - Ovid).

If you've ever used MS Project, you understand what I'm talking about - there are a large number of defaults to set up at the outset. Also, you need to understand the interplay between Resource assignments, Available Units, Task Type, Effort, Duration … and when (if ever!) to use the dreaded F9 (Level Resources).

Suggestion: start using MS Project now - even for the very small projects! It's like any other complex skill - the more you practice, the better you get. Why not work out the basic mechanics and concepts on simple projects; when the more complex ones  come around, it will just be a step-function higher in difficulty. (Practice makes perfect, walk before you run, etc.)

Three follow-up ideas on this topic, building on stuff from previous posts ...

Document Standard Process: As you develop your skills, you will undoubtedly develop preferences for options / defaults, ways to make your projects behave consistently. Take the time to document this stuff!

Templates Are Our Friends: With more projects under your belt, you should start to see reusable "components", like standard blocks of tasks for server configuration, application testing, etc. Also - start to build your reusable list of resources, standard calendars that fit your organization, etc.

MSP and PowerPoint Are Not Friends: Gantt charts direct from MSP are too complicated. If you must deliver project updates via PowerPoint,  better to develop a simplified Gantt visualization using Excel or Visio (examples here and here).
    Note: I have an Excel sheet I use to create Gantt "pictures" - not useful to track a project, but very nice to add a simple visual to a slide deck (click on the picture for a full-size image) ...

    It's not really ready for "prime time", but let me now if there is interest - I'll clean it up and post it here.
Remember, the intricacies of resource, task, and cost management with MSP are the easy part of project management - frees you up to work on communication and change management - where the Real Project Managers show their worth ...

Previously ...

Technorati Tags: , , , , ,

Invisible Technorati Tags: , ,
,,

Labels: , , , ,

posted by James P. MacLennan at 10:47 PM | Permalink | 0 Comments

Monday, September 29, 2008

Agile Methods in a Waterfall World: Speaking In Code

Starting up a new project, and I'm definitely having fun with it. At first glance, it looks like a fairly small, departmental application, but it is actually part of a web of disconnected processes and local databases (ie. "a mess") that support some fairly important master data. Also, the folks I'm working with are much more comfortable in a "waterfall world", with formal requirements followed by code, test, and deploy.

Lots of opportunity for process coaching and new methods - I've started notepads on data models, process maps, glossaries, even "best practice" lists for app dev processes like Requirements Gathering.

One session in particular was quite interesting. I am working with a developer on a Notes database, but I do not know the language (LotusScript, or whatever). Oh, I've seen it, and can figure out what's going on, but don't ask me to code anything! Anyway, the developer was educating me about "workflow", and the Notes app's propensity for spitting out email notification when Significant Things happened. When we clone the production database, we'll have to trap all of those emails, lest our testing process spams the department with meaningless links.

The developer started talking about a "global search" and a lot of hand coding, but I had a different idea. Not knowing the language, I just pulled up a screen and started typing VBA-like pseudo code ...

Is this how it currently works?
    Sub btnSendInfo_Click()

       Send Mail to samir@initech.com

    End Sub
 Yes

And you were going to fix it like this, right?
    Sub btnSendInfo_Click()

    '   Send Mail to samir@initech.com   ' comment out this line

       Send Mail to michael@initech.com

    End Sub
 Why, yes

What if we did something like this?
    Global Const iDebugMode = 0

    Function SendMailAddress( sAddress as String ) as String

       if iDebugMode = 1 then

          SendMailAddress = sAddress

       Else

          SendMailAddress = michael@initech.com

       End If

    End Function

    Sub btnSendInfo_Click()

    '   Send Mail to samir@initech.com ' comment out this line

       Send Mail to SendMailAddress( "samir@initech.com")

    End Sub

The neat thing was that I couldn't even finish typing some of these sections when the developer started assenting with verbalizations that indicated understanding (ie. "grunting acks"). He had seen some .Net stuff, I was mangling some of the syntax, but the basic pattern was easy to see. It was about 5 minutes of silence, save for the clicking of the keys - we were Speaking in Code, and it worked great!

Previously ...

Technorati Tags: , , ,
,

Invisible Technorati Tags:, , ,,

Labels: , , , ,

posted by James P. MacLennan at 10:50 PM | Permalink | 0 Comments

Wednesday, September 17, 2008

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: , , , , , , ,


Invisible Technorati Tags:
,
,
,
,

Labels: , , , , , ,

posted by James P. MacLennan at 9:26 PM | Permalink | 0 Comments

Friday, August 22, 2008

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

Technorati Tags: , , , , , ,

Invisible Technorati Tags: , , , , , ,

Labels: , , , , , , , ,

posted by James P. MacLennan at 10:39 PM | Permalink | 0 Comments