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

Monday, January 18, 2010

Data Visualization: How (2 of 2)

The short answer, as you know, is that it's impossible to tell you how to be insightful and imaginative in a single blog post. All I can do is point you in the general direction, and (hopefully) ignite a little spark.

What's the Goal? and, Where to Begin?

I previously talked about the growing calls for effective data visualizations; we have access to all this great information, and there are insights in there somewhere - but we need just the right point of view to rise above the cloud of data and see the real opportunity. It helps if you have experienced that rush of insight when looking at a particularly impactful graphic; not just a good looking slide, it calls out something important in a particularly effective way. Haven't we all watched that earnest TV lawyer pull the winning argument out of the blue [right before the final commercial break] and win the big case?

Of course, it's not enough just to want it - you have to have a little reverse-engineering in your soul. You need confidence & bravado (I can and should be able to create those killer pictures), hunger & curiosity (how did they do that?), and confidence to know that you can - with a little hacking. It also helps to have the blissful ignorance to assume that it's within your technical grasp.

Step 1: Find Someone who Knows - and Follow them Around!

I'm a big fan of the "follow him around" method for learning new technology - not classroom instruction, more like a series of specific examples of applied technology. I had seen plenty of examples of presentations that I thought were very effective, but I didn't understand what was happening, what exactly was making them so effective. I had to find someone that could talk about putting together effective presentations - and had the good fortune to attend a seminar by Edward Tufte. Sure, you get some nice books, great to page through - but like most technical manuals, they don't really make sense until you've watched Tufte deconstruct the graphics. I learned the importance of taking extraneous ink off the page, and how scale, color and shape can illustrate and/or obfuscate. I didn't walk away from that experience with specific skills as much as clarified ideas - and a hunger and curiosity for more.

Step 2: Find Lots of Examples - and Steal some Inspiration!

Over the past few months, I've been following a number of blogs dedicated to ideas around information visualization - more skilled practitioners to follow around! The links below to take you to particularly interesting examples; your task is to subscribe to them all and regularly scan for ideas ...

Information is Beautiful
Cool Infographics
Flowing Data
EagerEyes.org
Chart Porn
  • Haiti This blog is just a non-stop source of interesting examples
New York Times
Step 3: Get Your Coding Hands Dirty!

Remember, after you are done being wowed by the presentation - figure out how you could build one.
  • The old stalwart Excel comes with an ever growing list of graph types. Can't find the one you want? Try to hack at the standard stuff using VBA!
  • Sometimes a blog post will point you to some utilities. No, I never heard of Gource, but you can bet I'm looking for a project to use it with!
  • Open source has a lot of interesting tools out there - from jQuery addins to full-blown BI suites - lots of tools to load up with your data.
Remember - get inspired, find some starting points, and get building! the only way to really understand how to create insightful, impactful visualizations is to do a lot of experimentation.

Previously ...

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , , , ,

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

Tuesday, January 05, 2010

Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game

I've been working with internal developers over the past few weeks, experimenting with a treemap / heatmap-style visualization that is quite interesting / insightful when loaded up with data, but very tough to configure and manipulate. We are also struggling with a presentation layer (surrounding this data control) that doesn’t adapt to the size of your browser screen, or behave well when placed inside a frame set or table.

I suspect our primary challenge - typical thinking for most corporate IT departments - is that we only work with the tool we know. The only way to display information in a browser from XYZ's data warehouse is to use their particular Web portal platform. We need to switch focus; let the data warehouse provide beautifully aggregated and accessible data, but go elsewhere for the presentation layer.

Corporate IT needs to develop a sense of adventure, a thirst for new and different ways of doing the same thing, and a curiosity about different presentation architectures (ie. there's more than one way to skin a cat). Manufacture some spare time, and get down to some serious "play", with CSS, HTML, and SharePoint (as previously noted, our target intranet platform); learn all you can about the level of control you have. Note that you probably have more flexibility than you think … but now we're playing with JavaScript, VBScript, or any number of client-side technologies.

Unfortunately, we all seem to get to the same creativity-killing question: "how do I charge my time?". Full disclosure: I'm a big fan of the timesheets and reasonable chargeback systems, quantifying IT alignment with the business - but therein lies the subtle yet significant difference with "the IT guys" and the iPhone / iPod / Kindle / Nintendo / Best Buy expectations of our business partners.

Rewarding Different Behaviors

Corporate IT is measured by and rewarded for projects - specifically, getting things done. In most organizations, that's where it ends; IT is usually not rewarded based on the ongoing use of the project deliverables; in fact, ongoing support ("maintenance") is expected ... a cost of doing business ... overhead ... part of baseline costs ... and, in a manner of speaking: free (no premium is paid).

It’s the exact opposite on the Internet and consumer IT; you are expected to build the stuff for free, and just give it away. You will get your rewards when people come to your website, click on your ads, buy your products, become sales leads. You’re rewarded after the build is complete – but (if you are good), you are rewarded over and over again.
  • Corporate IT – metrics for success stop when the project is complete
  • Consumer IT – metrics for success start when the development work is done
This also helps explain why Consumer IT delivers "stuff" that people like, that is intuitive, easy to use, and just works. Witness the apple iStore – developers earn cash only when they sell their apps, long after the build is complete. But it's not as simple as that - note that even though there are a huge number of apps out there, less than 5% are big successes (>100,000 users). Competition and market dynamics drive quality and innovative, creativity is rewarded when an app rises above the fray. Check out the disturbing collection below; how many different ways can you write the same, silly, popgun program? You'd be amazed ...



... yet five minutes of playing with each of these shooters, and you start to see the subtle variations and evolving methods that applications that get the most return visits.

Hope for Corporate IT - the Anti-PMO

The iGun story tells us about the darwinian action that comes with large amounts of repetition, duplication, and failure. Success can be quantified by your failures - how many failed experiments have you thrown out there, just to see what sticks? On the internet, preferably a lot - because that’s how you learn what works, and how to make the “really cool stuff”.

Corporate IT might stand a chance in an environment where experimentation and failure is encouraged (but not necessarily rewarded - we need to learn from our mistakes). In essence, we need to build an anti-PMO and give permission for folks to do stuff that has no apparent value.

What will it take for you to facilitate a more creative environment? For more ideas on establishing an innovation environment, check out this old post ...

Previously ...

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , ,

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

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

Tuesday, August 18, 2009

Training and Learning: A Different POV

The topic was training users for an upcoming project rollout, and the debate (as always) roamed back and forth between "traditional" (classroom training, scripts & workbooks) versus "experiential", pairing existing users with their counterparts (who are new to the system), walking through the basics (screen navigation, terminology, and step-by-step instructions for the most common required tasks). Training methods are a common area of debate and discussion with system implementation folks, and I can make a great case for any and all sides.

Task Oriented

(This is where I adopt my Pat Buttram voice) I remember back in the day ... we had "green screens", text-based terminals running applications that flowed like the languages they were written in; procedural, top-down, ordered and neat. There was only one path through each process ("This is the way you set up a vendor and cut them a check ... This is the way you set up a lease and charge the rents ... "). The training material was also very orderly - each step of the process was lovingly detailed, keystroke for keystroke. For more aggressively user-friendly documentation / training material, authors included a screen print for every step of the way.
    Documentation Lament Part 1 - I typically take issue with folks who insist on a large number of screen prints. Yes, it appears user-friendly, but it's brutally difficult to keep a document like this up-to date and relevant. Even in the green screen days, we saw basic changes to the application that altered the screen's appearance. Since we're providing these images to provide users comfortable reassurance that what they see is what they are supposed to get, each change means a complete reshoot of all the affected screens. More trees die as page inserts and updates are distributed - and electronic distribution is not much simpler, as the document files are quite large, with chunky .BMP inserts that presented a challenge to all of those floppy-enabled sneakernets (back in the day).
High Concept

I remember when my kids were in their early grade school years; I was impressed to learn that some of the first math classes that they took were all about pattern recognition. Brilliant, I thought - that's the best way to learn how to work with the gooey (graphical user interface, or GUI) applications that were supplanting the chewy (character-based user interface, or CHUI) apps from the old days.

As computers became more powerful, programmers built apps to take on event-driven, flexible format tasks that matched the environments they were implemented on. Sure, there were wizards to take you through some basic operations, but when you're typing a document, manipulating artwork, or laying out your spreadsheet, there's no start-to-finish process - you are "creating". Training for this software is not about step-by-step processes, but complex operations built with common component tasks. The Microsoft Office suite taught us all that there are certain patterns to modern software (ribbon notwithstanding) - all menu bars were populated with the same basic component tasks. Top left always had File Open / Close, Edit Cut / Paste - and Help can always be found at the rightmost position of your menu bar.

The challenge, of course, is that not all people excel (so to speak) at conceptual learning. Us old folks grew up memorizing multiplication tables, and we've built our careers on a certain facility (based on familiarity) with the step-by-step.
    Documentation Lament Part 2 -  The practical document author should see to flexibility and fluidity of GUI applications as a valid reason to forgo the screen prints. There is so much variability to what is presented on the screen - especially when the latest stuff allows you to customize the appearance of menu bars and other options. Alas, the well-meaning training teams still insist on copious screen prints that are even more likely to differ from what the user sees on their screen. Why can't everybody just adopt Microsoft's online help style? The vast majority of it is text based - no screen prints, menu options described with subtly layered in-line constructs like File, Open. Elegant simplicity, and much easier to maintain.
Follow That Guy Around

Of course, the most common training method of all is the modern apprenticeship - follow someone around that knows what they are doing. For companies of all sizes, it still amazes me how many important processes are not documented. Some might claim they are forced into this modus operandi by expedience and/or a slimmed down the workforce; I think it's just human nature. It's hard to get people to effectively document how they do what they do.

Don't get me wrong - I freely admit my preference for this approach, especially when it comes to new programming languages. I can read a technical manual with the best of them, but I do like to have at least one sitdown with an experienced programmer, watching over the shoulder as they take me through the development cycle (edit, compile, debug, run). Just show me on the screen how it works; once I can do my first practical [hello world()], I can grab the book, refine my skills, and catch up on the theory.

Good, Bad ... I'm the guy with the gun

Truly, there is no right or wrong answer here. Different people learn things differently; some react better to the spoken word, other prefer the printed, and some folks need to have step-by-step instructions laid out for them. Note that I purposely do not suggest that procedural versus object-oriented learning is a generational thing; I know plenty of old folks that do just fine with the object-oriented, creative, free-form, self-directed style of learning.

The key is that trainer / communicators must be facile in many different methods, and quick to understand which method will work best for your target audience.

Previously ...

Technorati Tags: , ,

Invisible Technorati Tags: , , , ,



Labels: , , , , ,

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

Tuesday, August 04, 2009

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

Invisible Technorati Tags: , , , ,



Labels: , , , , , , ,

posted by James P. MacLennan at 9:44 PM | 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

Wednesday, February 04, 2009

Is SharePoint WSS dangerous to SharePoint contractors?

Firing Up Internal Opportunity

It was true last year, but even more so now; SharePoint is very important for corporate IT, both strategically (medium- and long-term) and tactically (short-term). Sure, it's a terrific way to iterate on collaboration, internal portals, document management, etc. - "enabling innovation" in every buzzword-compliant sense. But there is solid benefit for even short-sighted, plodding, tactical IT - and it's all about staff retention.

SharePoint WSS represents a nice opportunity for folks in IT to get some hands-on experience, building relevant (if small) applications with some "cutting edge" technology. Staying "cutting edge" is important for most IT folks, but let’s face it – most of us don't work in software development houses. The typical manufacturing company spends <3% of revenue on IT; on top of that, the current economy has everyone focused on cash flow. I was speaking with a vendor yesterday evening, who told of his interactions with IT management in multiple companies over the past few weeks - and the primary concerns all had to do with system availability and cost cutting.

This nuclear winter environment, freezing spend on training & tools, would typically drive all your best IT talent away - we all want to work on latest and greatest, and experience non-trivial growth in our skills. So, how might you feed this "edge mentality", with little or no cash?

SharePoint provides both sizzle and steak ** - it’s got market hype, it looks and feels significantly different than your current, boring green screen stuff, and it’s fast twitch (small projects, lower priority, low risk if something messes up). With all that going for it, it should be easy to get internal folks to work on the new, quick and dirty stuff that the business wants.
    ** Ok, maybe not Morton's, but it's not Steak and Shake, either!
Drying Up External Demand

Unfortunately, I think this leaves SharePoint consulting houses bereft of good opportunities. Cash-hoarding businesses turn inward for their development needs - and this time, they can get good-looking results!

I remember when .Net came out a few years ago - had a very enlightening conversation with a typical small-firm rep. Microsoft's new technology platform was great for sales, the story went, because the projects all took 30% less time than before (such a deal!) Unfortunately, the other shoe soon dropped, and the sales team had to generate 30% more business just to keep the pipeline full and billable hours flat to the previous year. The downward pressure on rates wasn't a help, either.

Stable [end-user] companies may not fear large turnover in the current economic client, but the good ones will continue to stress internal training and new technology skills. I see plenty of SharePoint interest (and resulting bandwidth) from internal IT - where will this leave the contractors?

Previously ...

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


Invisible Technorati Tags: , ,
, ,

Labels: , , , , , , ,

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

Monday, January 26, 2009

News for Wombats: Taming Unreasonable Requirements

I've heard from a couple of friends about some "classic" project requests - dilemmas they have recently faced. These unreasonable requests can be turned into something achievable and, potentially, more relevant / meaningful to the requestor, by approaching the problem from a different direction.

Request for Data: the Analytics Project

Classic scenario #1 arrives courtesy of the external Experts, analytic genii (sic) promising to reveal secrets of profitability and sources of revenue buried deep within our data sets. Their "simple request" is to pull all data from the system - customers and orders, vendors and payments, items and inventories - all classified by OBC; the Obvious and Brilliant Categories that, when summarized and sorted, will unlock our Big Opportunities.

Pulling data from the system is easy, but the desired attributes often do not exist in the system - or, they exist, but we have not (to date) filled in those details on our orders / payments / inventories. So, IT is asked to coordinate the bursting of data into separate spreadsheets, and distributing data sets to various areas of the business, to the people who know how to categorize the uncategorized.

Note the hidden work the consultants have pushed down. IT must frame the question to the business (can you categorize this data?), but they are often left with the task of explaining the original project and justifying this interruption. Remember, when the programmers came in this morning, this Data Collection project was not on their radar screen. Of course, this is perceived as IT resisting, being uncooperative ...

Sound familiar? It should, I've seen it at many companies, many functional areas of the business. There are some Obvious Truths that jump out when you think about this for a bit ...

  • The Data is not Missing - we just never collected it before. Truth is, if we were already categorizing data this way, we'd probably be paying attention to the Big Opportunities already!
  • You're Just Moving the Work from the analysts to IT. True, internal IT will probably know the quickest way to get the most accurate data, but why push off the communication / explanation stuff?
  • There is a Hint of Diminishing Returns here. If 100% of the data is categorized, a simple pivot table will elegantly show all the data, totaled by attribute and sorting the Big Targets to the top. However, most of the time spent is getting the "long tail" of special cases categorized; wasted work, because they won't make the Pareto cut.

Aha - that last one gives us a hint on how to slash the amount of work required to get actionable data in a reasonable amount of time. Haven't the external Experts seen data sets like this a million times? They are, after all, selling their experience in the problem space - why not engage in some targeted research? Based on experience, for companies of our type and size, what do you expect the answer to be? 

What cross selling opportunities are the most common?
What aggregate buying typically get the most bang for the buck?
Which product families are typically the slow movers?

Jump start the data categorization by guessing the Pareto sort, and target that data for characterization ...

  • Download 100% of the data – must always be able to do a hash total to prove we have it all
  • The download / work files have blank columns for every requested attribute
  • Scan through and mark all the data for the target category

Battling What "They" Say

A similar problem is often faced when proposing system and process change. A classic refuge of the change resistant is to stand behind an Unassailable Truism with a potential for problems ...

Not all of Our Vendors are ready for EDI ...
A great idea - but how will this impact The Customer?
You can't apply these changes to All Products ...

Well, yes, but this isn't helping us get to the benefits represented by this Cool New Thing; you are just defining Problems, not Solutions.

Still, this one can be fairly easy to defeat, by getting a bit more specific. Which vendors / customers / products are we talking about? Usually, there are just a few key instances where critical relationships (vendor or customer) must be maintained, or important product attributes will guide decisions / changes. Target these specifics, and don't try to develop solutions / rule sets that will work in all imaginable cases (diminishing returns, again).

News for Wombats

The phrase comes from an old Monty Python show, where a series of terribly redundant news programs, specific to parrots, gibbons, and wombats, pointed out that in all cases, "no parrots / gibbons / wombats were involved". (Hey - it's funny in context. Not everybody appreciates Fibber McGee, either). The point is - when time is of the essence, and you are looking to balance a complete design with relevant action, it helps to focus on the specifics.

Previously ...

Technorati Tags: , , ,

Invisible Technorati Tags: , , ,

Labels: , , ,

posted by James P. MacLennan at 7:44 PM | Permalink | 0 Comments

Saturday, January 17, 2009

Hacking the Google Chart API from Excel

a bit of code on a Saturday night ...

I've written before about a simple way to measure and report IT value to the business - quantifying alignment with strategic initiatives  project spend in context. It all culminated with a single, simple slide - numbers, with some Tufte-esque Sparklines thrown in.

Click on the picture for a full-size image!


Well, technologies come and go, and without going into the boring details, I've had to come up with a new way to generate the mini-bar charts along the left side there. It ended up being a relatively straightforward task in Excel VBA - yes, of course the table of data is being driven from a spreadsheet.

Here's the macro that does the trick - I just create a little HTML file that generate the bar charts in series (please excuse the hard-coding) ...

Sub CreateSparklinesDisplayFile()
  
   Dim sOutFile As String
   Dim iStartRow, iStopRow As Integer
   Dim iStartCol, iStopCol As Integer
   Dim i, j As Integer
   Dim sDataString As String

   sOutFile = "C:\Temp\BizUpdates.html"
   iStartRow = 45   ' First row of data to be graphed     <<< Evil hard coding!
   iStopRow = 51    ' Last row of data to be graphed
   iStartCol = 12   ' First column of data to be graphed (includes column of series names
   iStopCol = 24    ' Last column of data to be graphed

   Open sOutFile For Output As #1

   Print #1, "<html><head><title>BizUpdate Sparklines</title></head>"
   Print #1, "<body>"
   Print #1, "<p>Sparklines for last 12-months spend, IT Projects, by Initiative</p>"

   ' Loop thru the lines in the table to generate the separate sparklines

   For i = iStartRow To iStopRow
      Print #1, "<P>" & Cells(i, iStartCol).Value & "</P>"
      Print #1, "<img src='http://chart.apis.google.com/chart?"
      Print #1, "chs=100x35"       ' Size (length x height) of final graphic
  
      sDataString = "&chd=t:"
      For j = (iStartCol + 1) To (iStopCol - 3)
         sDataString = sDataString & Cells(i, j).Value & ","
      Next j
      sDataString = sDataString & "0,0,0|0,0,0,0,0,0,0,0,0"
      For j = (iStopCol - 2) To (iStopCol)
         sDataString = sDataString & "," & Cells(i, j).Value
      Next j
      Print #1, sDataString
 
      Print #1, "&cht=bvs"
      Print #1, "&chbh=a,2"
      Print #1, "&chco=CCCCCC,FF3300"
      Print #1, "&chds=0,100,0,100'"
      Print #1, "title='" & Cells(i, iStartCol).Value & "' />"
      Print #1, ""
   Next i

   Print #1, "</body>"
   Print #1, "</html>"

   Close #1

End Sub

The output file looks something like this (a simplified version ...)

<html><head><title>BizUpdate Sparklines</title></head>
<body>

<p>Sparklines for last 12-months spend, IT Projects, by Initiative</p>

<P>Cost Reduction</P>
<img src='http://chart.apis.google.com/chart?
chs=100x35
&chd=t:52.25,65.3,72.15,33.15,33.95,33.65,47.7,92.88,79.49,0,0,0|0,0,0,0,0,0,0,0,0,70.57,87.85,55.25
&cht=bvs
&chbh=a,2
&chco=CCCCCC,FF3300
&chds=0,100,0,100'
title='Cost Reduction' />

<P>Growth</P>
<img src='http://chart.apis.google.com/chart?
chs=100x35
&chd=t:67.05,88.25,85.61,95.25,86.70,55.49,54.75,81.19,65.62,0,0,0|0,0,0,0,0,0,0,0,0,55.65,42.05,18.41
&cht=bvs
&chbh=a,2
&chco=CCCCCC,FF3300
&chds=0,100,0,100'
title='Growth' />

</body>
</html>

Some things I noted when constructing this stuff ...
  • The Google Chart API seems to be picky about the order of the various parameters. I had some troubles getting the charts to work unless I output things just so
  • I can control a lot about these graphs, but I couldn't get rid of the x-axis. Yes, there is a chart type for "sparklines" (cht=ls), but that's for line graphs only
  • I am calling out the last three months spend in the table, so I want to highlight them in the charts, hence the little hiccup in the j loop
I can publish a version of my spreadsheet that puts it all together, just let me know ...

Previously ...

Technorati Tags: , , , , , , , ,


Invisible Technorati Tags: , ,
, ,

Labels: , , , , , , , ,

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

Sunday, December 07, 2008

Best Practices for Requirements Gathering Sessions

It's been a while since I've led an interactive requirements session for an interactive application - but it's kind of like riding a bike. After a few minutes, the old habits come back, and the iterative ideas and cascading creativity starts to flow. What has changed, however, is the application platform, the office environment, and the various knowledge capture tools at our disposal.

So, in the spirit of knowledge retention and sharing, here's a brain dump of ideas that make for a better requirements gathering session ...
  • Think of it as an interactive presentation - so all of the classic prep rules apply. Arrive early, get set up and have everything running before people arrive
  • Make sure you can bring the original application (if it's a rework) up on the screen: check in advance that you can attach to the network
  • The best sessions are interactive, with application mock-up tools. Have a copy of Visio, PowerPoint or something similar ready to go - so you can paint screens and interactively work things while they watch
  • Use a room with a big screen TV or projector, so your audience can "see over your shoulder" as you work. However, if possible, you should face your audience - have them look behind you at the screen / projection, while you look at the display on your laptop.
    • This allows you to have a conversation with the folks opining on needs and wants, and lets you see their facial expressions as you dummy stuff up.
    • This also allows your audience to see what you are typing. They are proofreading your work - not for typos, but to make sure their understanding of the words / ideas you are talking about are being captured correctly.
  • Make sure you know where the local printer is, and can print to it. Waiting for a series of changes to be "painted" on the screen may take too long; it might be easier just to take a print screen and mark it up
    • When sketching on paper, have a couple of different color pens on hand, and color-code your scribbles; red = follow up / things to fix, blue = talking points, etc. When capturing ideas on the hard copy, your fixes & follow-ups are easily distinguishable. A highlighter might be good idea, too.
  • re: typing / data capture: Consider using a simple text editor, Notepad or something similar. Key is not to worry to much about formatting the text or correcting typos. As long a you can decipher your hacking, that should be ok
    • However, a spell checking word processor might be preferable to Notepad - your typos will get automatically fixed up
  • Always number your requirements / items to attack. Then you have a finite, trackable list of stuff that is either go or no go
    • Consider creating an auto-numbered spreadsheet for a Requirements list - you can bring it up on the screen as well. Create additional columns for notes, resource assignments, effort estimates - stuff like that
  • Bring a digital voice recorder to the session. Let the folks know that they are being "taped" - but it's only so you can go back and replay the discussion while cleaning up your notes. This will also allow you to stop typing and continue the in depth conversation - which is where all the value is
  • Set clear expectations of what you want to accomplish in the meeting - and set a time limit; iterative work is easily digested when taken in small bites
There is a lot of power in truly collaborative requirements sessions - the ultimate users of your system will readily accept the results when they are truly part of the design process and experience.

Previously ...


Technorati Tags: , , ,

Invisible Technorati Tags: , , ,

Labels: , , ,

posted by James P. MacLennan at 7:05 PM | Permalink | 0 Comments