Have you ever noticed how much time and energy goes in to data validation? I think it stems from visual forms development and the wide variety of clever data entry controls that are available – everyone wants to write an app that gets the oooo, cool! vote of approval. But how much of that energy spills over from value-added to feature creep?

Regex complexity at its finest ...

When your IT peers are showing off their internally developed tools, or when internal departments put so much creativity into their departmental data collection apps, try stepping back for a moment and taking a look at the amount of development, documentation, training, and maintenance work that gets generated. These amazing, subtle, and visually compelling methods for gathering and validating data can become complex validation rules that try to guarantee that only pristine data is ever added to the list.

Is all of this really necessary? Is there real value-add to this approach? Often times the coding of validation rules is so complex that the code becomes fragile, and burdensome on future maintenance programmers. Another common problem – many specialized, departmental, and/or narrowly vertical applications have broad ranges of acceptable data – and the rules for permissible values need to be wildly flexible and adaptive.

But how about NOT validating the input? Why not let “market forces” take over?

I am talking about instances where people are trying to get data into a System That Makes Some Problem Visible – for example, a database of projects or technical resource requests that have to be prioritized, or financial data that has to successfully post into a centralized data collection / aggregation system.

It might be easier to just document the requirements for the data, and then let the best quality data survive …

For your Project / Resource Prioritization application, a project will not get added to the prioritization list until all the data is complete and correct. Even if it is complete, it helps to make the project description easy to understand, compelling, and business relevant – or else someone else will get the resources.

Your monthly data submission has to conform to these [data structure] rules. If it does not conform, it will be kicked out / flagged with errors. You are responsible for getting your data cleaned up and compliant with the specification, and your data submitted by [the deadline] – else your submission will be late.

Now, this does put pressure on us to document the data formats and requirements clearly – but this is probably faster and easier than creating a gallery of automated rule checkers to validate input. And, when the document is proven to be complete, correct, and sufficient (i.e. not too complex), it would make a pretty good spec for an automated data validation program.

Just a wacky idea – as system designers, we don’t have to control the world. Try making market forces work in your favor, just like content struggling for readership on the internet or new products looking for sales …

… may the cleanest data win!

thanks to ex-parrot for the regex from the illustration

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: corporate information systems, data management, internal development, maintenance, master data management, PMO, portfolio management, Requirements, software maintenance, software testing

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/market-driven-data-quality-data-darwinism/feed/ 1 http://www.cazh1.com/a-hierarchy-of-information-requirements/ http://www.cazh1.com/a-hierarchy-of-information-requirements/#comments Mon, 10 May 2010 02:24:29 +0000 Jim MacLennan http://www.cazh1.com/?p=469
It’s a common problem statement – ‘I don’t have enough information to (run my business unit, manage this process, identify opportunities, etc.)’. The solution designer, when faced with a question like this, starts with a little detective work; the problem is too broadly stated.

<aside> This part of the project is itself an example of the problem – “I don’t have enough information to define the problem of “I don’t have enough information to …’ “<aside>

And, after a little detective work, we will probably find one or more of the following is correct:

• The information [to run my business] does not exist (KM, BB)
• The information exists, but I do not know that it exists
  • I am unaware that it exists (KM)
  • I suspect it exists, but I do not know how to find it (KM)
  • I suspect it exists, but I cannot find it (KM, BB)
• The information exists, and I know that it exists, but I cannot access it
  • I am prevented from access due to security requirements (BB)
  • I have no data access tool (BB)
  • I have a data access tool, but I do not know where the data source is and how to connect to it (KM)
• The information exists, and I know that it exists, and I can access it, but I don’t understand what I am looking at
  • I do not know how to use the data access tool (KM)
  • I know how to use the data access tool, but I do not understand the domain / terms / concepts (KM, BB)
  • I know how to use the data access tool, I understand the domain, but I do not understand the data structures (KM)
  • I know how to use the data access tool, I understand the domain, but the metadata is confusing (KM, BB)
• The information exists, and I know that it exists, but I don’t want to access it – I want my team to access it, and feed me the results
  • My team complains about issues above (?!?)
  • My team only answers my questions – they don’t do any proactive analysis (KM)

A wide range of root causes, and as you read down the list, it’s easy to imagine the range of solutions that could be brought to bear. I have broadly classified solutions for these problems in the list:

• KM – Knowledge Management: Some level of documentation, training, knowledge capture, and/or knowledge sharing will be involved
• BB – Build or Buy: Includes any technical work, like building a custom solutions, buying and implementing packaged software, and/or configuring the software / information store.

I find it interesting that KM is required in almost all (10 of 13) of the solution cases above, and a “technology solution” (aka I need to Build or Buy something) is required less than half of the time (7 of 13). And how about that little People Management issue that sneaks in near the end …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | One comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/a-hierarchy-of-information-requirements/feed/ 1 http://www.cazh1.com/news-for-wombats-taming-unreasonable-requirements/ http://www.cazh1.com/news-for-wombats-taming-unreasonable-requirements/#comments Tue, 27 Jan 2009 01:44:00 +0000 Jim MacLennan http://qc.cazh1.com/?p=288 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.

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.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags: analytics, communicating complexity, data, data management, data warehousing, feature, materials management, procurement, Requirements, sales

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/news-for-wombats-taming-unreasonable-requirements/feed/ 0 http://www.cazh1.com/do-you-want-it-good-or-fast-prioritizing-time-to-value-over-requirements/ http://www.cazh1.com/do-you-want-it-good-or-fast-prioritizing-time-to-value-over-requirements/#comments Mon, 11 Feb 2008 03:43:00 +0000 Jim MacLennan http://qc.cazh1.com/?p=229 I have a background in software product development, iterative “methodologies”, and the sort of fast-twitch life cycle that characterizes entrepreneurial startups, high-growing businesses, and “lean” process improvement projects. Unfortunately, this style is also favored by departmental developer wannabes, sloppy coders, and impatient Gen-Y newbies that want to apply a consumer products mentality to corporate IT.

<aside>Yes, I’m throwing a bit of a challenge out with that last statement. I understand that as the demographics of my IT team changes, management style must change as well. However, notwithstanding CIO Magazine’s recent deluge of articles urging oldies like me to “get with it”, and embrace Web 2.0 flexibility, there are certain immutable facts that fly in the face of the recent college graduates urged to apply social networking, text messaging, and torrent-enabled IP sharing to the 9-to-5 grind … but I’ll save that for a later post … </aside>

The real challenge is understanding how to introduce this new and different way of thinking (about projects and project delivery) into an environment rooted in audits and controls, waterfall methodologies, and tightly integrated ERP. Nothing wrong with any of these – in fact, for work in and around your run-the-business systems, there’s nothing more comforting than the rigor of requirements, testing, and a controlled promotion process.

Still, many organizations focus on the wrong legs of the Iron Triangle. Let’s assume that budget, if not absolutely fixed, is at least severely constrained (again, we’re not talking about a fast growth company that has money to burn). At this point, the typical IT department – laboring under the twin misconceptions that the customer is always right, and the business understands the difference between wants and needs – dutifully captures all requirements, and work commences until there is nothing left to do. With budget and requirements “fixed”, time is the variable, and projects go on for months.

I don’t mean to sound cynical – sometimes it’s not a question of kitchen sink requirements (as in, “everything but the …”). Feature creep can also set in when folks want to develop code to test for every scenario or use-case. Even something as simple as adding type codes for a given transaction; believing in the power of metrics, folks will come up with a descriptor for every conceivable exception – regardless of the frequency or relevance.

I think the biggest difference between these organizations and their iterative brethren – startups, fast-growth, and “lean” organizations – is a focus on time to value. Established companies have predictable sales cycles, quarterly statements, and six month planning horizons; it’s not about speed, it’s about getting it right.

Established companies start to struggle with time to value when their environment changes. This is when a subtle change in project management style can go a long way towards liberating the locked-in value of these powerful organizations. Focus on that third leg of the triangle, and learn how to manage a project to a date. I have to be done in 60 days – what can I get done in that much time?

Sometimes this leads to a counter-intuitive decision. For example, a make-to-stock company may have established a Microsoft standard for desktop systems, but a new line of custom engineered, make-to-order products may need to hire in a team of Macintosh-wielding product designers that must be productive on Day 1. In the long run, I may need to replace their new workstations, but I’m certainly not going to slow down the launch of a profitable new line while my standards team goes through a lengthy RFP and vetting process.

Another common mistake – or maybe a defensive mechanism for those well-grounded in the status quo. Sometimes people “give up” on the idea of getting projects done in a short amount of time – “nothing happens quickly here”. I maintain that we give up on the idea of getting it done quickly, because we’re not giving up on the demand for 100% requirements. If we insist that the work must be done in 60 days, we will have to give up some of the nice-to-haves.

This is the big change management challenge before us – prioritize time to value over requirements, and focus on the 20% of the work that will deliver 80% of the value.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | No comment |
Post tags: budget, business benefits, business value, customer, feature, functional design, iron triangle, project cost, Project Management, Requirements, time to value

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/do-you-want-it-good-or-fast-prioritizing-time-to-value-over-requirements/feed/ 0 http://www.cazh1.com/strategies-for-malware-in-consulting-engagements/ http://www.cazh1.com/strategies-for-malware-in-consulting-engagements/#comments Sun, 28 May 2006 15:45:00 +0000 Jim MacLennan http://qc.cazh1.com/?p=131 Last in a series on some practical legal mumbo jumbo (disclaimer: IANAL) for your Master Consulting Agreements (MCA). This one was particularly interesting to put in; it’s really interesting to see who catches it, but it was an amazing (in retrospect) observation that led us to include the language.

The Trigger Event: A virus outbreak. We had been hit before, and the executive group was not fond of losing their email for a day or two, so we implemented fairly tight lockdowns to get things under control – email scanning, virus signature updates pushed via SMS, aggressive patching for IE, and plenty of email warnings against opening mystery attachments. After many months with no outbreaks, we were surprised when we got hit fairly bad one summer. When we traced to the source of the outbreak, we found it was a consultant’s PC – woefully behind in OS and Virus patches and updates.

Our Director of Operations was rightfully peeved, as his group put in a lot of overtime to get things cleaned up. Especially aggravating / amazing was the fact that this consultant was working for a technology vendor, helping us on a major, high-profile technology implementation.

How can you trust a consultant’s tech skills when they can’t even perform the basics on their own PC?

Well, we lost the argument for a credit on their next invoice, but we did make a change to our standard MCA, adding the following sections:

[contractor] agrees that it has installed virus checking software on all computers owned by [contractor] that will be attached to [company]‘s wide area network, and that the virus tables are being updated at intervals exceeding no greater than 7 days. [contractor] also agrees that the virus checking software is run continuously to monitor the state of these computers and is additionally used to check external media. [contractor] agrees that all external media brought onto [company] premises shall be scanned for viruses by a member of [company]‘s IT staff designated by the [company], prior to installation of said media on any of [company]‘s computer equipment.

[contractor] agrees that it has installed all appropriate Microsoft software updates (also known as Critical Updates and Service Packs) on all computers owned by [contractor] that will be attached to the [company]‘s wide area network and that run any version of Microsoft Windows. [contractor] agrees that all computers brought onto [company] premises shall be checked for Critical Updates and Service Packs by a member of [company]‘s IT staff designated by the [company], prior to connection of said computer to [company]‘s wide area network.

Should a virus, worm, or security breach be deemed by [company] to be introduced to the system by [contractor], [contractor] will at its expense and [company]’s sole choice either repair the damage to any and all affected machine(s) or reload the machine(s) with the most recent valid full backup and update it with the incremental backups provided said backups are available, current and valid.

This is always good for a comment from the contractor / consultant, but these are (I feel) fairly common sense additions, and very simple to enforce.

1. The easiest way to avoid any problems is to not attach your Windows PC to my network. Insist on using my PCs, my licensed copies of development / productivity tools, etc. This approach actually solves other issues, like software licensing and internet access controls.
2. For an operations group with good, tight processes, it literally takes minutes to check for the latest pathes and virus signatures.
3. At the very least, this focuses attention on the consulting firm’s technical abilities. How should you feel when the expensive tech expertise does not have confidence in their own controls?

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2006. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/strategies-for-malware-in-consulting-engagements/feed/ 0 http://www.cazh1.com/strategies-for-risk-sharing-in-consulting-engagements/ http://www.cazh1.com/strategies-for-risk-sharing-in-consulting-engagements/#comments Sat, 13 May 2006 05:14:00 +0000 Jim MacLennan http://qc.cazh1.com/?p=129 I am late is responding to a comment on this post, first in a series about Consulting Engagements. Earlier this week it was Intellectual Property, with another good comment … so, why all the harsh language about protecting IP that I probably can’t commercialize? Ah – welcome to the world of Risk Sharing.

The issue is that most businesses, especially SMBs that are simply not used to paying $200 an hour for labor, typically have a tough time wrapping their minds around a relationship that has such large invoices with no guarantee of success. It is easy for the cynical to see how a consulting firm can milk an arrangement for tons of $$ without delivering the hoped-for business benefit.

<aside> Please, no comments about the chronic lack of requirements and/or tight process. Yes, I am fully aware that many customers of professional service firms really don’t have a good idea about what they need or want, and don’t have a good understanding of the value proposition of a good consultant / developer / integrator. This is about how to bridge that gap … </aside>

First, get the fee structure in place (“not to exceed”) that will put some controls in, but give the contractor the proper trigger to control scope creep.

Next – how might we put something of interest into the agreement, that gives me, the customer, a little hedge against the risk of the unknown? This could and should work both ways – it gives the contractor a differentiating value proposition, while focusing their attention on the project, to see it though to the end.

I’ve seen a couple of different approaches …

1. Penalty / Bonus for Hitting the Date: This method will penalizes the contractor for failure to meet the time table [within it’s control], and reward them if deliverables and the work plan are met. This particular example provides a 2-to-1 incentive ratio in favor of the customer; we hold back 10% of the fees due to the contractor, and pay back the 10% plus 5% incremental upon periodic approval by a Project Steering Committee, which judges if performance is proceeding satisfactorily and on time.
2. Budget Risk Sharing: Given a project budget, the contractor agrees to a final review when work is complete. If the contractor comes in under budget, the customer agrees to pay 25% of the difference as a performance bonus. If, however, we blow the original budget, but the work needs to continue, the contractor agrees to discount their ongoing hourly fees by 25%. We can also agree to a max budget overrun beyond which no additional $$ are owed, but the work will continue until completion.
3. Gain Sharing: The typical project has a cost/benefit model that defines how long the payback is; these models are typically built with the help of the contractor. One way to keep the benefits estimates realistic would be to reward the contractor with a % of any additional savings beyond, say, 20% of the business-case estimate. Of course, could also penalize the contractor should the benefits come in less than expected.
4. IP Rights: Finally, realize the inherent value in the Intellectual Property created, and the fact that the contractor is typically (thank you Gemignani) better suited to commercialize the stuff, by granting IP rights in exchange for lower hourly rates.

Of course, all of these agreements will require lots of specific language and guidelines and limits and, above all, excellent levels of open, honest communciation through the life of the project – but hey, all that will do is foster an even better environment for a successful project!

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2006. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/strategies-for-risk-sharing-in-consulting-engagements/feed/ 0 http://www.cazh1.com/your-outlook-schedule-looks-like-a-game-of-tetris/ http://www.cazh1.com/your-outlook-schedule-looks-like-a-game-of-tetris/#comments Wed, 06 Jul 2005 03:32:00 +0000 Jim MacLennan http://qc.cazh1.com/?p=80 Interesting meetings, discussions from last week; as a former consulting partner once noticed, my calendar in Outlook usually looks like a game of Tetris, with back-to-back meetings, double bookings, etc. It was actually quite energizing for me last week, because the meetings were on wildly divergent topics covering lots of areas.

Side note: This scheduling style means I seem to be a few minutes late for each meeting – but then again, so are the other folks, so I guess flexibility is a good general rule (but it’s still not a good thing to do regularly).

Some highlights:

• With the tech team … two separate cases of push-back from the group on issues, purely on technical considerations. However, my counter-arguments are typically along the lines of “there is a billion dollar project on hold for want of this feature / flexibility”, or “critical commitments have been made to management / customers / supply chain”, or what have you. When the argument against is that it’s technically the “wrong thing to do“, or “it’s long term maintenance expense” – man, you are losing the forest for the trees. The ongoing struggle is to get tech folks to see the overriding business reasons why we do what we do.
• Running a meeting with “lively discussion” … I like to preface meetings by apologizing for my (soon to be) abrasive style, for comments yet to be said that might be potentially embarrassing or offensive – and I also offer the prediction that the meeting will end with an edict from me, not a vote. Sounds combative, but the apologetic style usually works, and I’m trying to make sure the folks in the room really feel that we can all speak freely, question each other’s approach, and drive down to the best resolution for the issue(s) at hand. Also, I make sure to end the meeting with an apology again, and a quick follow-up chat with one or two that I know might have been “offended”. They usually aren’t, but it’s key to aggressively balance a drive-to-results style with real respect for peoples’ feelings – some day you’ll have to ask that person to run a gauntlet, loyalty goes both ways, etc.
• Requirements gathering meetings I … my favorite method is playing dumb (note: more “apologizing” for “dumb questions”), but this allows me to ask truly basic questions, real 5 whys stuff. I love asking the ultimate dumb question – “Why are we doing this task at all? What is the objective / point? What if we don’t do this activity? Note that you shouldn’t just ask how they do these steps, drill into the why – if there is no reason to do xyz, then don’t (and then we won’t have to automate it). (Corollary: the good programmer / systems developer is often lazy … more on that for another post …)
• Requirements gathering meetings II … Also, one effective way to manage scope / expectations is to lay down levels of functionality. For any report / query / program, establish a bare minimum bit of functionality, then go for a slightly nicer to have description, and so on. Note – early in the process, you should keep the “home run” super feature possibilities under your hat, at least until you get a proof-of-concept working … don’t want to set expectations to high (under promise, over-deliver).

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | No comment |
Post tags: feature, functional design, internal development, iterative development, meetings, Requirements, teams, workgroup

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/your-outlook-schedule-looks-like-a-game-of-tetris/feed/ 0 http://www.cazh1.com/things-for-the-diy-programmer-to-consider/ http://www.cazh1.com/things-for-the-diy-programmer-to-consider/#comments Tue, 15 Mar 2005 03:11:00 +0000 Jim MacLennan http://qc.cazh1.com/?p=48 Things for the DIY programmer to consider

Another thought-provoking post on Thinking Faster – he sounds like my business doppelganger …

When considering the option to build vs. buy, or at least involve corporate IT and/or experienced developers, most folks with a business background miss some key considerations about their approach:

1. Is robust multi-user required? Excel spreadsheets deal with this challenge rather effectively – like a book, one user at a time. Access opens the door, but most business developers don’t appreciate common multiple user issues like record locking.
2. Does it scale? Related to #1 above – how many records until the spreadsheet or database starts to show some strain? Also, with databases, the tradeoffs for multiple indexes (report / query speed vs. transactional overhead) are typically not considered.
3. Version Control, Configuration Management, and Deployment – Getting the software to work on your own machine is quite different than managing the ongoing maintenance and deployment to multiple machines.

I suppose I could go on, but those are usually my favorite three gotchas when working with internal groups.

Now, hopefully I don’t sound too elitist or dismissive of folks that want to do internal development like this. On the contrary, I applaud their aggressive nature, encourage their application of technology to business, and appreciate the cost / time-to-value argument they can often make. However, it is our task in IT to make sure the Total Cost of any technology decision is thought through.

One passing comment – I just love it when folks say “but this is such a great idea … maybe, when it’s done, we could commercialize it!” It never fails – it has happened in every company I’ve ever worked for … ah, the lure of miniscule COGS (hey, blank CDs are cheap, right?). I then get to regale them with tales of woe from my developer days …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | No comment |
Post tags: cost, Development, internal, internal development, scale, TCO

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/things-for-the-diy-programmer-to-consider/feed/ 0 http://www.cazh1.com/does-it-make-you-productive-or-are-you-an-existentialist-or-a-fatalist/ http://www.cazh1.com/does-it-make-you-productive-or-are-you-an-existentialist-or-a-fatalist/#comments Sat, 26 Feb 2005 19:12:00 +0000 Jim MacLennan http://qc.cazh1.com/?p=46 Interesting article in Thinking Faster, just getting around to capturing my comments …

On Requirements

“The first reason that business folks don’t get what they need from IT is because they aren’t sure what they want”

The fundamental challenge of capturing and managing knowledge – it’s much easier to understand something than it is to describe, document, teach it. Why do so many organizations do knowledge transfer and training by saying “follow that person around for 3 months”? Of course, there are multiple ways to address this, my favorite being Rapid Application Development (RAD), where the iterative cycle of conversation / quick requirements capture, prototype / get something working, review change / improve, makes it easier for folks that can’t sit down and write up a complete, well-thought-out design architecture. The challenge (offset by patient explanations and participatory solution development) is to get folks to understand that this is not instant, it’s a growing process.

On Information (not Data)

“These systems are great at everyday transaction processing, but fairly poor at providing information to help people make decisions”

We’re struggling with this right now, with a new business system that does not provide easy data access via simple spreadsheet / query tools. The sad yet classic search for the magical silver bullet, with folks insisting that six-figure investments for graphical reporting tools will make all the problems disappear. We’re fairly confident that the complexities of the typical ERP data model will generate far more questions, but the key observation is that analytics are often an afterthought.

Another point here – the classic mistake IT makes all of the time is the assumption that the business folks are unable to comprehend the concepts and complexities of “reporting”. Come on – it’s 2005, basic Data Processing classes are at the heart of all undergrad business degrees, and everyone knows the amazing things folks do with their spreadsheets … IT must give some basic credit to folks looking for information like “show me the customers in these three cities who bought this type of filter over a year ago .. I want to sell them a replacement filter, they are due …”.

On Technobabble

“What reinforces this problem is … IT people … tend to talk in three and four letter acronyms and argue about the benefits of Java or .NET”

I’m fascinated by those that make this argument / observation, yet themselves speak in terms of SG&A, EBITDA, COGS (Finance), absorption, phantoms, PPV (Operations), and CPI, MPS, impressions (Marketing). Every area of business has their own set of acronyms, concepts, and terms, and so does every vertical industry. It’s just as tough for the IT group to have to wade through the “native language” of five different areas within the same organization.

However, I do agree with the observation that business people treat IT as a mystery – maybe not most of them, and this is absolutely not a young vs. old observation. I know plenty of IT folks that wish business folks would behave predictably, like the 1′s and 0′s of their digital world.

I like to think of the self-empowerment question – are you who you say you are? Do you have control / responsibility for your environment? The existentialist takes ownership, understands all the tools, drivers, forces, options, and figures out what needs to be understood to get the job done. The fatalist identifies reasons for their lack of results, and rails against the wind.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | No comment |
Post tags: Application Development, Communication, communication style, Design, knowledge transfer, RAD, Rapid Application Development, Requirements

All articles, blog entries, and other content on this site are licensed under a Creative Commons License    ]]> http://www.cazh1.com/does-it-make-you-productive-or-are-you-an-existentialist-or-a-fatalist/feed/ 0