Builders and Business People

I spent this past weekend building a fence... well... not quite.
I spent this past weekend watching Juan and Jose build a fence.

I live just east of Santa Fe, New Mexico... and out here many folks have what's known as a "Coyote Fence".  Juan and Jose are local craftsmen who (among other skills) are very good at building this type of fence.

My wife and I laid out the boundaries with stakes and twine, and then told Juan what we wanted (Juan's the eldest brother - so he handles the negotiations).  I had all the materials on site prior to arrival, so when the guys showed up on Saturday morning they got right to work and had the project completed by Sunday afternoon.

During the build, Juan noticed a few things I'd asked for that were (in retrospect) just plain crazy.  For one, I had the gate swinging the wrong way - He brought that to my attention and we changed the plan on the spot.  My wife also had to run to the store to get some items I'd missed, but otherwise Juan and Jose worked like demons and I got to sit by and watch.

I could have built this fence myself.  I've done similar projects in the past, and I'm not "that" old.  It's hard work, but not more than I can handle...  But I chose to "pay the experts" instead of building it myself.
They do this for a living... I make my living doing other things.

By now you've probably figured out that there's a lesson here that goes beyond home improvement...

I am a huge fan of enabling Business folks to build their own software solutions, but the fact remains that most people prefer to pay others rather than build things for themselves.  No matter how "business friendly" our tools become, most businesses will bring in builders when they need them.

The keys to success for a business software project are the same as those which made my weekend project a success.  The Clients (Teri and I) were able to lay out the boundaries and effectively communicate our requirements to the Builders (Juan and Jose).  One of the Clients (me) knew enough about building to be able to effectively monitor the work, and someone empowered to make decisions (my wife Teri) was on hand to resolve any issues that came up (screwy gate orientation).  The engagement was further enhanced by the professionalism of the Builder (Juan) to make suggestions.

 Let's go a bit further though and note an important distinction between my fence project and a typical business software project... the solution that the Builders supplied for me is completely "open".  I can see how it's put together, and I can see how to extend the solution.  For example, with tools that I know how to use I will be able to add another gate should I ever need one.  If the fence ever needs repairs, I know enough to be able to implement those repairs (but I'll probably just call Juan again).

This is where "Tools" for the Business folks have their place...  Give the Business folks tools that allow them to "see" what's been built and to provide the answers that they need when it's time to make a change... and they'll be happier and you'll be happier...

... But I'm willing to bet they'll still call you to build "it" rather than built "it" themselves ;-)

Templates and Frameworks

Sandy Kemsley posted a nice BPM Success Story "BPM Rapid Development Methodology" that has jogged me into publishing some thoughts I've been having about Templates and Frameworks as they relate to successful Business involvement in software projects.

Sandy relates:

"They’ve established best practices and templates for their user interface design, greatly reducing the time required and improving consistency. They’ve built in a number of usability measures, such as reducing navigation and presenting only the information required at a specific step. I think that this type of standardization is something rarely done in the user interface end of BPMS development, and I can see how it would accelerate their development efforts. It’s also interesting that they moved away from cowboy-style development into a more disciplined approach, even while implementing Agile: the two are definitely not mutually exclusive."

"This new methodology and best practices – resulting in a lean BPM team of analysts, PMs, developers, testers and report writers – have  allowed them to complete five large projects incorporating 127 different processes in the past year. Their business analysts actually design the processes, involving the developers only for the technical bindings; this means that the BAs do about 50% of the “development”, which is what all of the BPMS vendors will tell you should be happening, but rarely actually happens in practice."

Admittedly I am drawn to this case study because their methodology and best practices mirror my own leanings...  With the right approach Business folks really can drive (rather than be chauffeured around by the Technical folks).

Note that Sandy's tale mentions Templates, but it doesn't say a thing about Frameworks... and to me that's very significant...

As a Professional Programmer, my life revolved around Frameworks (OWL, MFC, Struts, Spring, etc.)  Each of these Frameworks provided a wonderfully powerful foundation on which I could build my custom applications.  I simply can't imagine life as a Professional Programmer without programming Frameworks.

Pardon me for over-simplifying, but a Framework is something that "you bolt pieces on to".  The Framework provides the internal structure of your program, and you can build many diverse and wonderful programs on top of any really good Framework.

If you are an Occasional Business Programmer you've probably found that Frameworks aren't quite what you're looking for.  Frameworks are really powerful and really flexible - but all that power and flexibility comes at a price - you really have to know what you're doing to use them.

Contrast Frameworks with Templates... a Template is something where you "fill in the details".  The outcome of using a particular Template is always the same thing - the implementation details may be wildly different, but as long as those details "stay in the box" your result is going to be what you set out to build.

Historically the Technical folks have built the Templates and the Business folks have "filled them in" (usually using wizards) - but our BPM Suites are showing us that the converse can be equally as powerful - Business can build some of the Templates (for the process) and the Techies can "fill in the details".

It's all about Requirements and Constraints.   Business folks can use Templates to convey Business Requirements to Technical folks, and Technical folks can use Templates to provide a "sandbox" within which Business folks can safely play (without breaking anything).

If you are a Business Guy composing a solution, and the "component " that you need doesn't yet exist, then just build a Template, ask your Techie colleague to "fill it in", and keep on going... You can't get much more rapid than that.

Tasks and Time

Tasks are always associated with time... Tasks are started at some point in time and they are completed at some point in time.  We're almost always interested in the duration (how long it takes) from the Start Time to the Completion Time.

Start Time and Completion Time are the biggies, but there are a few more timestamps that we're often interested in capturing (especially when tasks are performed by humans).  Here's my list:

• Assignment Time - the point in time when the task is assigned to a person (or group).  In most of the process applications I've implemented we don't assign a task to a person until that task is ready to start... but sometimes we do know who should work on a task long before the task should start. If we relate this in terms of an appointment on your calendar, this would be the time when you made the appointment.

• Scheduled/Estimated Start Time - the point in time when the human should (ideally) start working on the task.  In many process applications we don't predict when a task should start - it simply starts when the process flow reaches the task.  Explicitly scheduling or estimating start times can be very useful if you need to determine whether or not a specific process is "on track" to complete on time.
• Ready To Start Time - the point in time when everything is ready for work to begin on the task.  
• Start Time (aka Actual Start Time) - the point in time when the human starts working the task. It's our fondest hope that the Scheduled Start Time, Start Time and Ready To Start Time are all the same - but when dealing with humans they seldom are.

• Scheduled/Estimated Completion Time - the point in time when the task should be completed.  This is really an expression of "how long the task should take".  In most cases I've seen this set by adding the expected duration of the task to the Start Time - but there are cases where a hard and fast completion time is critical if you need to know whether or not the process can complete on time.
• Completion Time (aka Actual Completion Time) - the point in time when the human completes the task.

There are also some optional timestamps we need from time to time that you may encounter:

• Reassignment Time - It happens... and there can be multiple of these for a single task instance.
• Task Cancelled Time - Often good to know - not every task gets executed to completion.
• Task Escalated Time - This might possibly be redundant, since reassignment and cancellation are very common elements of task escalation.
• Task Suspended Time - Sometimes things come up and work on a task just has to stop. As with reassignment, this can happen multiple times per task.
• Task Resumed Time - If a task was suspended, you will almost certainly want to know how long it was suspended.

Analysis of all of these timestamps can help you figure out whether or not your process is running smoothly.  For example, whenever the actual Start Time is later than the Scheduled/Estimated Start Time you may have a problem... but to determine where the problems lies you'll need to take a look at the Ready To Start Time.  Was the human slow in starting the work, or was there a delay that prevented the human from starting the work?

In all honesty, I've never worked with a client who captured all of these timestamps for every task... and I am certainly not advocating that you should complicate your solutions by capturing this information unless you really need to.  Just don't be surprised in those rare instances that you encounter a process analyst who needs this level of detail.

If you've encountered requirements for capturing additional task oriented timestamps (or you have better descriptions/names for these timestamps), I'd love to hear about them.