cazh1 » Application Development

Sorting with Sound

Jim MacLennan — Tue, 24 Aug 2010 00:31:48 +0000

via Geek.com – yes, I subscribe to stuff like this in my RSS reader …

I thought this was interesting on two levels …

The Engineering student within appreciates the differences in sorting techniques (although I think I could speed up that bubble sort …)
I also think these videos provide a simple illustration of the power of multi-media information sharing; the audio helps the animated “description” of the sorting techniques

I freely admit to be a bubble-sort bigot, as I never truly understood the heapsort algorithm. But think how this combination visualization / audio tool helps illustrate the concept; I’d love to see an interactive tool that lets me step through the sort and see the loops and the “stack” of values.

Another important power of effective visualizations – they get your audience thinking in new and different ways as well!

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: algorithms, Art, coder, communicating complexity, elegant, interesting stuff, multi-media information sharing, programming, Science, sort, sound, stack, subtlety, technical communication, video, visualization, YouTube

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

A Hierarchy of Information Requirements

Jim MacLennan — Mon, 10 May 2010 02:24:29 +0000

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.

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 …’ “

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

Best Practices for Requirements Gathering Sessions

Jim MacLennan — Mon, 08 Dec 2008 01:05:00 +0000

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 …

Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
The Iron Triangle – Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Another caveat for the erstwhile agile developer (January 15, 2007)
Innovation That Matters – Substance Over Style (January 12, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)

Technorati Tags: best practice, design, development, innovation

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

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Agile Methods in a Waterfall World: Speaking In Code

Jim MacLennan — Tue, 30 Sep 2008 03:50:00 +0000

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?

Yes

And you were going to fix it like this, right?

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 …

Beermat App Development (October 18, 2004)
The good and the bad about being a hands-on tech manager (January 25, 2005)
Communicating Complex Technical Concepts (March 21, 2005)
Tech shorthand, a minor interest (June 3, 2005)
The “Army Rangers” model for IT Professionals (January 2, 2006)
Funny, how techies talk to each other (September 11, 2006)
The Joy of Programming, the Challenge of KM (May 5, 2007)

Technorati Tags: best practice, collaboration, development,
hands on, tech management

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

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Why are those Old Programmers so slow in picking up on the Intarweb?

Jim MacLennan — Sun, 06 Apr 2008 05:13:00 +0000

A significant difference between us old-line IT coders and the new graduates is the variety of our platforms and tools. I’m not talking about the large number of languages and tools learned over the course of a career – we all have a healthy collection of certifications and acronyms peppering the bottoms of our resumes. I’m talking about the amazing array of stuff required to get development done on a single project, “right now”.

Over the past few weeks, I’ve been doing a little development at work. This is my idea of fun – in between the PowerPoints and project status meetings, I try to sneak in a little hack or two. Actually, I’m not doing the heavy lifting on this one; I’m working with one of the guys on my team, and we’re putting together some ASP code to generate RSS feeds from the SQL database we use to track our projects. He’s done most of the raw research and the base coding, I’m just prettying up the final package.

As a department, we’re moving towards Microsoft as a strategic platform, but we’re certainly not there yet – so this is definitely a skunkworks-type project. For this “fun stuff”, we’re using technologies that will plug nicely into our general strategic direction, but at this point there are no standard toolsets or integrated development environments in broad use.

So, to get the job done this afternoon, I’ve been cycling through the following …

In window #1, editing the .ASP file with Crimson; source files are sitting on the development server
In window #2, testing code using IE … no integrated debug environment for my ASP syntax, but I manage (just a little trickery – switches flip between RSS and HTML output)
This is just debugging the basic code – to validate the RSS XML, I View Source from IE (opening window #3) and cut and paste into the W3C validator (window #4)
For the SQL queries and database hacking, I’ve got window #5 for Enterprise Manager and #6 for Query Analyzer
After debugging, I push to the test server manually, using File Explorer in windows #7 and #8
Everything looks great, so I switch to window #9, which has another chunk of ASP that generates custom URLs for the RSS feed (we’ve added selectivity, aren’t we crafty?)
For the final test, I have RSS Bandit open in window #10. I create multiple new feed URLs (#9) and add to the Bandit config, to see what I get
If I made a syntax error in the RSS (missed something between #4 and here), I have to flip back to window #1 to clean it up
Oops, almost forgot … like any good coder, I’ve got TFMs open, but it’s not just one manual- window #11 is my multi-tabbed Firefox, Googling all sorts of sites to get references for RSS, ASP, and SQL

Sounds crazy, I know. I could/should go out and get Visual Studio or something. But like I said, we’re not fully in production in this Microsoft development environment. We’re innovating, right?

I’ve done open source development on my own in the past, and it’s much the same thing – multiple different platforms, tools, and languages. For example, when working on my own site, I’m fixing configuration files and writing code in HTML, CSS, PHP, and mySQL. To get things working, I’m dealing with the configuration files for Apache, Eclipse, PHP, and mySQL. Edits in Eclipse and Crimson, pushing around source with FTP, fighting firewalls and routers, developing in Windows while production is in Unix.

This madhouse of multiple tools, languages, and platforms probably sounds quite normal – if you’ve been working heavy with open source and/or Web 2.0 for a few years. But imagine presenting this to legacy IT folks, working in their version controlled, standardized environments. The typical “road to the future” brings five new technologies, three new IDEs, and one or two basic system architectures that are all very different from tried and true.

Does this mean you can’t teach an old dog new tricks? Not at all – most are quite anxious to learn, and have done so continuously over the years. However, this is all starting to feel like the first time we switched from procedural languages (COBOL, RPG, Pascal, Fortran) to OO and event-driven stuff (Visual Basic, PowerBuilder, SQLWindows). We went from offense to defense, from being controlling and orchestrating to reacting and trapping. Not that it was bad or wrong – just different.

Does this mean the experienced coder is washed up, and has nothing to contribute? Ask the folks in Big Pharma, having dealt with the FDA and validated systems. Ask the folks working with Finance in public companies, having dealt with SarbOx. Healthcare and HIPAA. Retail and RFID. Not to mention having to debug a lot of other people’s code, and knowing when to step through or just refactor.

Running to the future, juggling multiple multilingual windows, and demonstrated facility with the newest tools is all good, but it’s just one of many attributes that determine who on your team is worth 50 others. Have a little patience …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | No comment |
Post tags: Crimson, debug, Development, Gen-X, hands on experience, HTML, millennials, MySQL, PHP, PowerBuilder, SQLWindows, usability, user interface, visual, XML

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Tactics for Controlling Project Scope

Jim MacLennan — Sat, 05 Jan 2008 06:36:00 +0000

I wrote about ways to “cheat” at project prioritization [aka trying to figure out what to work on next, when there is more demand (projects) than supply (people to work on them)]. One significant tool you have at your disposal is controlling scope – can you do 20% of the work to get 80% of the benefits?

Easier said than done, sometimes you need tactics, that help identify an opportune place to stop, a run-on project, or a design that is”simple enough”.

Apply the Law of Diminishing Returns “in reverse”, and front load the benefits. Let’s say we’re implementing a series of components (people, process, and technology) to analyze and improve promotion response. If I really understand the ROI, can I break it up into chunks? In this case, you might see a basic software package that defines master data, collects transactions, and provides basic metrics for promotion response. Let’s say this visibility allows you to realize 70-80% of the benefits,
but we want to follow with “phase 2″ where we add training, tuning, and optimization to get another 20 to 30% of your ROI. Well, time and resources are short – why not stop at phase 1, let the new processes soak in, and “optimize” later?
Eliminate the 90-percent Done game – Projects that run-on forever sap the energy out of your teams, and destroy credibility with the business units whose projects are getting delayed. Via Vinson, here’s an excellent post from Blain that reference’s Zeno’s Paradox
(I’ll never get there if I keep traveling half of the remaining distance …). The primary tactic is to define discrete deliverables (tasks?) and only accept a binary status – it’s either done or it ain’t!
Keep It Simple, Sir! Feature creep is the greatest enemy of the short-term project. Some features (like quality / testing) are not what you’d want to negotiate out of the project. Thinking about cutting short on documentation? You naughty, normal person … However, take a look at this
post from Sierra, with a great illustration of the idea that usability is optimized right before the user has to reach for the manual!

Click on the picture for a full-size image!

The folks at Big Contacts liked the idea so much, they tout it as a feature …

With Big Contacts there is no user manual. Because once you create a user manual, you are admitting your application is too difficult and that people need a book to use it.

Let’s steal that idea for our projects. No documentation required, because the deliverables (process, technology) are simple and common sense enough that people don’t need a manual, a training class, etc.

Ok, maybe it’s not “practical”, but it’s a Worthy Goal that could help keep scope down to a dull roar …

Previously …

Challenges when demoing / training / pitching complex systems (May 23, 2005)
Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
Subdivide a huge project list to simplify the prioritization process (October 27, 2005)
Misapplying the Pareto principle (January 7, 2006)
Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle – Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Another caveat for the erstwhile agile developer (January 15, 2007)
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
Defining the Business Value of a Project (October 25, 2007)
PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
PMO Prioritization – Project Descriptions should be Effective, Relevant … and Short! (December 9, 2007)
How to Cheat at the PMO Prioritization Game (December 14, 2007)
How to Win at the PMO Prioritization Game (December 18, 2007)

Technorati Tags: business value, documentation, PMO, Project Management, tech management, training

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

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Hidden Gold in Automating Recurring Processes

Jim MacLennan — Mon, 28 May 2007 16:48:00 +0000

Here’s a typical IT scenario: each quarter, you need to check audit user access to a critical application. Your internal security standards require that you revoke access for those who haven’t been on the system for over 90 days. I’ve seen this before, and the process (at the time) had many challenges:

It’s manual; we did a quick-and-dirty set of steps years ago to cover the minimum requirements, that involves extracts from application logs, file transfers MS Access and MS Excel, and some emails
It’s not drop-dead simple, because there is a list of exceptions – user IDs that were always kept active, even if they haven’t been used
The overall process was never documented

Coupled with the fact that this only happened once per quarter, and involved less than five total effort hours to take care of, the easy response was to just get the task done and move on. But I think this is penny wise and pound foolish; there are long-term quality Problems to be avoided, and short-term Opportunities for internal staff development that we were passing up!

Problem: If we continued to just do the minimum, to satisfy the requirement, it was no surprise that over time, steps were omitted. The lack of documentation forced folks to repeat steps from memory, and pass along the process word-of-mouth as roles rotated and/or people turned over.

Opportunity: Simplifying things required some automation; nothing too difficult, but definitely interesting and non-trivial; for example, we needed a custom table for the exceptions. For staff members looking to build technical skills, this was a perfect training opportunity; small risk, small time requirement – a perfect filler when you are burnt out on the big project and need a bit of an escape.

Of course, the push-back was always the same: I Have No Time For This. Most can easily envision a total solution that is simple, uses familiar technology, gets rid of the multiple platforms and manual processes, and is sustainable. In this case, however, it would take about 16-32 effort hours to get done, and who has the time?

The solution was to attack the problem in baby steps; make the overall process a little better each time. For isses like this, you don’t need to solve all of your problems now, and it’s OK to leave the work unfinished until next time. However, the key is that you must commit to making a small improvement each time you “touch” the thing.

For example – back to the user access audit. For a first pass …

The current task owners walked through the process with me, and I took scratchy notes on paper and in a Notepad text file – stashed on my hard disk
I got the Access database extract and Excel spreadsheet that counted the days. I iterated on the spreadsheet, automating the counts and the formulas for computing days since last log in.
I returned the list of users who hadn’t signed in for 90 days, which were then manually matched against the list of exception user IDs.

This work was a one-time add of about three effort hours – a small start, but a teeny platform on which to build.

A few months go by, and it’s time for pass two …

I moved my scratchy notes into a shared document and iterated on the process, mostly just cleaning them up to be somewhat legible
I still received the list of users and their last access date, but this time I got the list of exceptions. I iterated on the spreadsheet to take this into account
I still sent the results back, but note that now (and never again) does the next person in the process need to edit out the exceptions

This work was another one-time add of two or three hours; but we’d already simplified the overall process, and we saw the total effort (including process improvements) starting to decline.

Next iteration …

We teed up a programming project to build an exception table and automate the log extracts – nothing more than a couple hours of effort
I took a final cut at the process documentation in the shared area, then turned it over to the operational support team

Note that each time you iterate on something like this, you need to feel comfortable with the idea that these works in process, these “interim deliverables”, are clearly unfinished, even raggedy. It shouldn’t matter, because each time you touch it, it gets a little bit better. Plus, the priority was originally low enough that a totally manual effort was OK, so what’s wrong with documentation that is incomplete?

Incremental improvements on the primary goal (automated user audits) with tasty side benefits along the way (mini side projects to keep stretching your tech chops) … win-win.

Technorati Tags: productivity

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

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Strategies for Malware in Consulting Engagements

Jim MacLennan — Sun, 28 May 2006 15:45:00 +0000

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.

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.
For an operations group with good, tight processes, it literally takes minutes to check for the latest pathes and virus signatures.
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

Strategies for Risk Sharing in Consulting Engagements

Jim MacLennan — Sat, 13 May 2006 05:14:00 +0000

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.

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 …

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

Components, IT Responsiveness, and the Rosemont Horizon

Jim MacLennan — Thu, 23 Jun 2005 01:31:00 +0000

Technical people are often engineers at heart, and really want to see controlled processes in and around their computer systems. We see source code control, configuration management, and process documentation as ways to manage long term maintenance costs and deliver repeatable, reliable results from our systems.

In the realm of ERP systems, this would seem to be a common and well-regarded mind set; however, the businesses supported by these systems often demand information transparency, process flexibility, and quick turnaround of change requests. After all, the customer is always right, right? So, how can we quickly make changes in a structured way? How can we deliver repeatable, reliable systems while maintaining flexibility?

I often hear of process and/or technology mavens erring on the side of too much control. IT seems to prefer this approach, and I hear it a lot when I talk with folks in and out of my company. Of course, the opposite extreme (no-questions-asked flexibility, without concern for long-term maintenance issues) is a slow-cooking recipe for disaster.

One of my favorite analogies on this topic is my Rosemont Horizon story. The Horizon is/was a medium-sized arena northwest of Chicago, now called the Allstate Arena (but it’ll always be the Horizon to me), and featuring your typical eclectic array of “stuff” every month – rock concerts, basketball games, tractor pulls, wrestling, circuses … good times …

Picture the stagehands at the Rosemont on one hypothetical summer weekend; the Rolling Stones are playing on Thursday and Friday, and need a regular stage with a long runway extending into the audience, as Mick Jagger likes to strut out, jump up and down, and let the crowd hear and see him up close. However, on Saturday and Sunday, there is a Garth Brooks concert, and Garth prefers the wide stage with a lot of space along the front for fans to get up close. This is key – a long runway on Friday, and a wide stage by the next night. Note also that Mick jumps up and down, and Garth smashes guitars – so the stage better be sturdy, solid, and reliable (mistakes [stage "downtime"?!] will cost $$$).

One might erect a custom-built wood structure with tons of two-by-fours and bracing; this will be exactly (to the nail!) what Mick requires, but the weight would be immense (immovable!) and the whole thing would have to be torn down and rebuilt in an afternoon for Garth – expensive and extremely difficult, requiring high skill sets for your stage crew. This is clearly not the preferred approach; generally, you’ll see lightweight, sectional staging that is built up from many basic shapes, quickly assembled into any configuration and taken down again, but rigid and strong when assembled.

Ok, so this is a better analogy for component-based architecture, I know, but bear with me; the real magic comes in the detailed instructions / processes involved. Each of the components are highly engineered, with interchangeable connections and standard “interfaces”. Also – and this is key – there are detailed installation instructions to make assembly quick as can be, and you typically wouldn’t have to maintain a staff with a specialized skill set to put this stuff up. The rigor and process design is implemented at the component level – individual sections cannot be redesigned, but you can mix and match and find the best solution for any particular rock concert / business process. The flexibility comes in when you are interacting with the band manager / business process owner, trying to figure out the best way to provide for their requirements while still maintaining control of the environment.

A well-structured, well-educated process should not mean bureaucracy and delay, it should mean execution speed coupled with rigorous process control and auditability.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2005. | Permalink | One comment |
Post tags: allstate arena, analogies, application support, architecture, business process, Chicago, components, Documentation, flexibility, functional design, integration technology, maintenance, process documentation, Requirements, rosemont horizon, stagehands

All articles, blog entries, and other content on this site are licensed under a Creative Commons License