On Systems

Using a balanced consideration of People and Process to create efficient systems.

As much as I’d like to say it did, R. Alliance did not come to being without some effort. It was not the magical result of fairies riding unicorns waving their wands, issuing into existence a shiny new methodology for project-preparedness and process optimization based on consideration for people. It was not an easy transition but we survived, R. Alliance was borne, and we are better people for it.

Both Chris and I instinctively knew that we were on to something right from the first moment that we started talking about forming a company that put our professional experiences side by side. The pragmatic realization of this, however, took months of work that was, admittedly, at times painful to get through. Our collaboration styles clashed, we discussed and debated how we would present our services, and we built tools together that we didn’t always fully see the value of until they were done.

And we emerged on the other end of this effort with a new company. As we make no bones about repeating in our Web site materials and blogs up until this point (I promise we’ll start blogging about other stuff – next week), our company is one built on the premise that considering People and Process equally is what creates highly efficient Systems.

In the interest of full disclosure, I’m not sure either of us knew exactly what this meant – at first. We both intuitively knew we were on to something though, and at the end we emerged with the complete picture of project readiness that we had hoped for when we started. We built a system brick by brick, applying the methodology that we were building as we built it.

What we learned as we did this was that all too often systems are far less effective than they have the potential to be. Computer systems, systems of organization, and even environmental systems within a workplace – all suffer when their design doesn’t equally consider process (how, when, and where things are done) and people (who they are done by and why they are done). This isn’t new information – the simple fact that Use Cases exist shows us that designers of computer systems recognize the need to know who will be using their system and why it is being built.

Unfortunately, what we’ve noticed is that important strategies like these tend to fade away from daily practice on project teams when pressure to deliver builds. They tend to be sacrificed as being less important than other strategies, like those that have to do with actually building and deploying the solution. It’s hard to argue with this decision when budgets and timelines start to be overrun, especially because in the end a system is still built. But when this happens a system’s effectiveness dips and its cost rises. As a result, more “less important” pieces of the strategy are dropped, which lowers efficiencies, and…

You can see where I’m going with this. It’s one thing to correct a project that is failing completely. It’s much more difficult, however, to identify and correct missing or incomplete pieces of a project strategy well before they start to erode the effectiveness of a project solution. The elements we throw out of the overall plan because they seem to be a distraction to the short term results of getting something useful finished, are the same things that maintain project success both short term and long term.

In other words, not documenting Use Cases when building software because the process seems to slow things down up front and the value (or R.O.I.) isn’t immediate or obvious isn’t always the best approach. Understanding who it’s for and why it’s done, and then refining and customizing the what, where, and when of the process is far better.

When we say we are helping our clients build effective systems, we’re not preaching academically and hoping that things will get better as a result. We’re sharing the lessons that we’ve learned through our years of effective experience in the field; we’re taking what we have seen fail and illustrating how to avoid that; we’re admitting that we’ve struggled through the same challenges that our clients are. While we may not have the perfect solutions to everything, our combined approach is one that we know works. Because we’ve made it work throughout our careers and we use it ourselves here at R. Alliance.

There is a saying I remember seeing posted on my mother’s bulletin board in the kitchen growing up that’s really stuck with me, especially when things haven’t gone as well as I’d have liked them to:

“Wise men learn from their mistakes. Wiser men learn from the mistakes of others.”

And this is what we mean when we say we’ve done the heavy lifting so that you don’t have to.


Inspired by that Quote?  Us too!  Keep it and your thoughts on this post at www.MeetMaple.com

Originally Published on 8/16/2011

Written by Scott

Scott Waletzko built Maple with his bare hands, and is the managing partner responsible for all things technical at R. Alliance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s