Confused Chimp

There are roughly 3 models of consulting being practiced in the Kansas City market.  Two of these 3 models are vendor-based models and 1 is a partnership-based model which I will explain below. A vendor-based model is one that looks very similar to a relationship someone may have with their plumber, mechanic, or cleaning people.  This model doesn’t value relationship nearly as much as it values the façade of control and value.  The first 2 I will be talking about follow the vendor-based pattern that is popular and well-known in our community today.

Vendor-Based Staffing Model

These types of firm typically came from a staffing agency.  Dealing with these agencies can oftentimes be as challenging as placing an ad in CareerBuilder.  Clients tend to have to sift through countless firms before they find one that shows the ability to deliver quality talent honestly and with integrity.  This model was formed for a couple of different reasons.  The primary being as a result of market forces that made placing people difficult.  The other reason was more simple…they had resumes and they had companies needing bodies, so why not?

A staffing agency’s competitive advantage comes from their ability to compete on price.  Secondary to the bottom dollar, comes value and continuity for the client.  Their resources are not committed to their firm nor to the client and turnover is extremely high.  Value is the other concern in working with these vendors as the resources are extremely hit-or-miss with missing occurring far to often.  These firms have an inability to know what to look for as far as talent and background as referenced by the many times I have been contacted by staffing firms asking me what a skill was so they could talk halfway intelligently about it.

Relationships with these companies, while something of a gamble, work for some clients as they may get a hit on a valued resource or have the staff to sift out the talented from those lacking.  More often than not, I have found many companies in our area disillusioned by staffing firms playing at professional consulting firms and do not recommend this model for anyone.

Vendor-Based “Name Brand” Model

These types of firms rely almost solely on the “wow” factor for their success.  I say “almost” only so far as many of these companies also rely on their reputation from past successes.  The best advice I can give on this point is past successes are NOT always indicators of future success.

A branded models’ competitive advantage comes from the ability to “wow” the client with large and very formal presentations.  While these flashy performances and personalities speak well for a company, I’ve found these people tend to disappear shortly after the project is in full swing and are replaced by the same low-end talent often found in the staffing pool spoken about above.  These companies tend to rely on patterns and practices drilled into the heads of their consultants to bring a project to success.

Furthermore, the projects tend to run hidden in a veil of paperwork and process and are extremely fat on bureaucratic inefficiencies.  Presence is everything to these companies but always bear in mind, success is measured by the margins on every project they become involved in.  These companies will do whatever is necessary to protect those margins and keep them in a range that keeps them gainfully employed thereby firmly establishing them in the “vendor-based” space they live in.

The Partner-Based Model

A partner-based model is just like what its name infers.  It has focus on relationships and value first, with literally everything else secondary to that.  At the core of this approach is education and building trust upfront.  This has become a necessity as most potential clients have had negative experiences with a consulting firm at some time in their past.  Since this is the approach that AdventureTech takes, let’s take a closer look at how we implement this model.

AdventureTech’s Partner-Based Model

AdventureTech was built by seeing the failed traditional models spoken about above and molding a model that better fit the personalities and traits that make up a successful software development company in the Midwest market. Our model tends to focus on an extremely open process and working in the organization as opposed to for the organization. In every project that AdventureTech is involved, our clients have intimate knowledge of the details. Now the pros of this are apparent…clients know what they’re getting, when they’re getting it, and all the inner workings of the project.  The cons are some clients do not want all of that as they do not think they can provide enough value to make that worthwhile.  We come alongside our clients to show them the truth that a project simply will not be as successful as it could or should be minus a business’ direct involvement as partners on the team.

AdventureTech sets itself apart from the staffing model by employing well-known talent in the market as full-time employees.  Our primary competitive advantage comes from our knowledge and understanding that our greatest asset is our employees.

In addition to that, we shy away from the “name brand” model mentioned above simply because that is not who we are.  First of all, we aren’t nearly as good looking as those guys and girls but second of all, we are developers through and through.  From the top level management to the lowest level employee, we roll up our sleeves and get right into the heart of our clients businesses.  There is no one in our organization too proud or too far removed from the technology that they can’t sit down and begin coding today and many are actively doing so.  Therefore, we remove the flashy and somewhat shallow presentations with rich education that our clients can comprehend and base sound business and technical decisions on.

The competitive advantage that is so unique to our partner-based model comes from the quality of our people, an open process, and a willingness to come alongside our clients as a part of their organization.  Having a relationship with AdventureTech means not just the investment of capital in a project but investing your organization’s time and energy in the software development process.  This is something most companies have little to no experience being involved in, but is an essential ingredient to the success of all of our endeavors.  It is challenging to develop software, but rather than trying to hide this challenge in hard to understand technical bureaucracy and process, AdventureTech puts our clients on the team to build software as efficiently and effectively as possible.

Did you like this? Share it:

Takaka, New ZealandI happened to catch a Charlie Rose interview last night with George Schultz – former US Secretary of State.

Now in his 90's, he still has coherent and interesting things to say. This part of the interview particularly caught my attention, and it's as relavent to his field as it is to general business:

Charlie: “You’ve always had this relationship between academia […] and business, and you’ve always believed that […] policy ought to begin with big ideas.”

Schultz: “If you don’t have ideas, you don’t have a compass; you’re just steering by the wind … You’ve got to have a strategy. We’re just reeling around and throwing money all over the place.”

 

 

Did you like this? Share it:

(Musical key change.)

Not long ago I finished reading “Delivering Happiness” by Tony Hsieh. It’s a great yarn about how he created the powerhouse, Zappos.com.

There were a number of things that resonated with me in the book, as they relate to AdventureTech, but the sentiment that still ranks the highest is his philosophy on change which I simply can’t improve upon.

 

Part of being in a growing company is that change is constant. For some people, especially those who come from bigger companies, the constant change can be somewhat unsettling at first. If you are not prepared to deal with constant change, then you probably are not a good fit for the company.

We must all learn not only to not fear change, but to embrace it enthusiastically and, perhaps even more important[ly], encourage and drive it. We must always plan for and be prepared for constant change.

Although change can and will come from all directions, it’s important that most of the changes in the company are driven from the bottom up – from the people who are on the front lines, closer to the customers and/or issues.

Never accept or be too comfortable with the status quo, because the companies that get into trouble are historically the ones that aren’t able to adapt to change and respond quickly enough.

We are ever evolving. If we want to continue to stay ahead of our competition, we must continually change and keep them guessing. Others can copy our images, our shipping, and the overall look of our Web site, but they cannot copy our people, our culture, or our service. And they will not be able to evolve as fast as we can as long as embracing constant change is part of our culture.

Ask yourself: How do you plan and prepare for change? Do you view new challenges optimistically? Do you encourage and drive change? How do you encourage more change to be driven from the bottom up?

Are you empowering your direct reports to drive change?

Did you like this? Share it:

As part of our rebranding efforts, AdventureTech advertised alongside our listing with the new verbiage and copy we've been working on over the last 9 months.

Along with our new website, we're extremely excited to be telling Kansas City about who we are and what we are about.

We feel this advertisement encompases those messages and look forward to a great year in 2011 where we can take those ideas to our community.

Did you like this? Share it:

I have been using Rhino.Mocks pretty much since I started being a mockist-type tester. I have been very happy with it for the most part, but a year or so ago, I got a glimpse of some tests using Moq. I thought the little bit I saw was very compelling. For a long time, I had been using:

   1: var _repository = MockRepository.GenerateMock<IRepository>();

   2: _repository.Expect(repo=>repo.SomeCall()).Return(SomeValue);

   3: var _controller = new SomeKindaController(_repository);

   4:  

   5: ... some exercising code

   6: _repository.AssertWasCalled(repo => repo.SomeCall());

 

I was happy with that syntax. I didn’t go looking for something else, but what I saw was:

   1: var _repository = new Mock();

 

And I thought, “That looks really nice!” The code was very expressive and easier to read that the Rhino.Mocks syntax. I have gotten so used to the Rhino.Mocks syntax that it made complete sense to me, but to developers I was mentoring in mocking, it was sometimes to obtuse.

SO I thought I would write some tests using Moq as my mocking tool. But I discovered something ugly once I got into it. The way Mocks are created makes Moq very easy to read, but that only gives you a Mock not the object itself, which is what you’ll need to pass to the exercising code. So this is what it ends up looking like:

   1: var _repository = new Mock<IRepository>();

   2: _repository.SetUp(repo=>repo.SomeCall).Returns(SomeValue);

   3: var _controller = new SomeKindaController(_repository.Object);

   4: .. some exercizing code

   5: _repository.Verify(repo => repo.SomeCall());

 

Two things jump out at me: 1) when I set up my mocked calls, do I set it on the Mock or the Mock’s “object”? and 2) What am I verifying on SomeCall? Just that it was called? that it is available to call? Dealing with 2 objects, a “Mock” and an “Object” made me have to consider naming conventions. Should I always call the mock _repositoryMock and the object _repository? So I went back to Rhino.Mocks. It is the most widely used framework, and show other how to use it is easier because there is one natural object to use, the _repository.

Then I came across a blog post from Patrik Hägne, and that led me to a post about FakeItEasy. I went to the Google Code site and when I saw the syntax, I got very excited. Then I read the wiki page where Patrik stated why he wrote FakeItEasy, and it mirrored my own experience. So I began to play with it a bit. So far, I am sold. the syntax is VERY easy to read and the fluent interface is super discoverable. It basically looks like this:

   1: var _repository = A.Fake<IRepository>();

   2: a.CallTo(repo=>repo.SomeMethod()).Returns(SomeValue);

   3: var _controller = new SomeKindaController(_repository);

   4: ... some exercising code

   5: A.CallTo(() => _repository.SOmeMethod()).MustHaveHappened();

 

Very nice. But is it mature? It’s only been around a couple of years, so will I be giving up some thing that I use a lot because it hasn’t been implemented yet? I doesn’t seem so. As I read more examples and posts from Patrik, he has some pretty complex scenarios. He even has support for VB.NET!

So if you are looking for a mocking framework that looks and feels very natural, try out FakeItEasy!

 
Did you like this? Share it:

Connect With Us

     

Contact Us

Toll Free: (888) 373-8718
Main: (913) 402-9600
Fax: (913) 402-9603
7450 W. 130th Street
Suite 320
Overland Park, KS 66213

Upcoming events

There are currently no upcoming events.

Recent tweets