Kinetic Data Acquires Mobile Web App Developer :coderow

Today we announced our acquisition of :coderow, a Minneapolis-based development shop specialized in building mobile apps and desktop web applications for business and consumer markets. You can read the official announcement here and also a nice article about the acquisition from the Business Journal here.

Kinetic Data acquires :coderowThe acquisition brings :coderow founder Kelly Heikkila back to Kinetic Data. Kelly joined us as a software developer in 2000, and by 2004, had risen to Director of Product Development, based on both his technical skills and leadership abilities.

Though the company grew and prospered, Kelly had always wanted to start his own company, and in 2008 decided it was “now or never.” He launched and built :coderow into a successful specialty development firm with a mix of consumer and b2b clients—including Kinetic Data, which contracted with :coderow in 2010 to help build the web UI for Kinetic Request, and later to assist in the development of the award-winning Kinetic Info product.

The acquisition will bring Kelly and a team of six developers with skills in iOS and Adroid app design, and Ruby and Java development, into the Kinetic Data fold. It will help us accelerate our pace of new product releases and mobilization of Kinetic Data applications.

:coderow’s experience in consumer mobile apps will also enhance Kinetic Data’s initiatives supporting the consumerization of IT and enterprise request management (ERM).

Looking Back at 100: The Top 10 Posts on Kinetic Vision (So Far)

Noisemakers! Confetti! Party hats!

Welcome to the 100th post on the Kinetic Vision blog. Hopefully most of the posts here thus far have been enlightening. Many seem to have struck a cord. A few have even generated a bit of controversy.

Post 100 on the Kinetic Vision blog
Image Credit: Wikimedia

In celebration of this milestone, below are the top 10 (or so) most highly viewed posts on the blog since its inception in March 2011, in reverse order. So, cue mental drumroll please…

Honorable Mention

Forrester Research Outsourcing Trends—How Service Providers Can Capitalize
December 21, 2011

Forrester Research Service Provider Analyst Pascal Matzke’s outlined trends that are leading service providers to change their business models.

10 Key Benefits of a Business Service Catalog: Forrester Research, Part 2
August 27, 2013

Service catalogs reduce the time and cost of delivering technical services while improving the user experience. But the benefits of needn’t be limited to IT.

#10 (tie)

How Forrester’s Smart Process Apps Fit with Enterprise Request Management
May 20, 2013

Forrester Research predicts Smart Process Apps will simplify business process workflows in the future. Here’s how to realize many of the benefits today.

How to Calculate the Cost Savings from Automated Self-Service
July 10, 2013

Automated request management self-service accelerates the delivery process, improves accuracy, and reduces costs. Here’s how to calculate the potential return.

#9

What is this “Level 0” thing?
May 16, 2012

What exactly is “Shift to the Left” or “Level 0,” and is it the future of IT help desk support and service delivery?

#8

The ROI of IT Support Improvements (Think Big)
July 30, 2013

It’s intuitively logical that improving support processes saves money. What’s surprising is the level of cost savings achievable with even small improvements.

 #7

Kinetic Calendar Gives Building Materials Giant Solid Insight into Environmental Permitting and Testing Requirements
July 6, 2011

Kinetic Calendar is a surprisingly simple to deploy off-the-shelf BMC Remedy application. And it works seamlessly with custom-built BMC Remedy applications.

#6

Agile Service Request Management
July 26, 2012

Given that agile approaches have proven to improve productivity and quality, now may be the time to examine the agility of your service request management system.

#5

Lotus Notes Apps Find a New Home in Kinetic Request
August 7, 2012

How do you replace the functionality of all the Lotus Notes applications you’ve built over time to automate workflows and business processes? Here’s an answer.

#4

Four Ways to Make Business Processes Better, Cheaper AND Faster
August 6, 2013

Today’s customers expect it all. But how can businesses provide outcomes that are better, faster and cheaper all at once? Here are four key approaches.

#3

Three Keys to Making Multi-tenancy Work
March 29, 2012

Not all multi-tenant applications are alike. Their cost and value are heavily dependent on these three architectural and design considerations.

#2

Eliciting Requirements for a Successful IT Project
July 26, 2011

In order to elicit, we must go further to reach a common understanding with the customer that sets the expectations in a documented way.

And finally, the most-read post on the Kinetic Vision blog thus far. With almost twice as many views as the second-most popular post, this one has been read by one out of every 11 blog visitors to date…

#1

Automating Employee Onboarding and Provisioning Processes with Request Management
June 12, 2012

Employee onboarding and provisioning activities that are coordinated and orchestrated with a request management application are improved in a number of ways.

That’s it, the most popular posts on the blog to date. As stated in the inaugural post here, our mission with the Kinetic Data blog was “to provide an objective and informative business service management blog where experts can provide thought leadership and interact with you.”

That hasn’t changed, though our focus has expanded to cover the world of enterprise request management. Hopefully the next 100 posts here will continue to inspire new ideas, debate, evaluation, and ultimately—business improvement.

Lessons Learned for Successful Request Projects – How to Scale the Heights of Success, not Plumb the Depths of Despair

It is rather surreal doing this blog post. I feel as if I am in a re-run of “Back to the Future.”

I am putting the finishing touches on this post before I present the session KEG, but because my internal clock is still set to Australian time, I am really doing it on the day after. These are some of the problems in living life “Down Under,” or as we Australians think of it, “Up Over.”

Australia- Up Over

 

Other problems include the “two nations separated by a common language”  that I encounter every time I visit. Please don’t ask me what team I “root” for or whether I would like to buy a Denver souvenir “fanny-pack.” Be careful asking me the way to the “bathroom” as it will get the response: “I’ve got a bath in my room, haven’t you?” We only have loos, dunnies, lavs, bogs or, if in polite company, toilets, and I take great delight in directing any American visitors to the room in my house that has only a hand-basin, shower and bath and not the other small room that has the toilet pedestal and watching their faces when they return with cleaner hands but a slightly more distressed look.

But enough of the cultural differences.

A little about myself and why you may be sitting in this presentation (if so, please put the iPad away and look at me) or reading this alone in your office or home (I assume because you have come to such a boring moment in your life when reading a blog entry of mine adds some excitement).

Well, I discovered the other day—through an automated message sent by our internal version of Facebook called Yammer (hopefully I get something for the plug—but not another bloody t-shirt please) that I have been with Kinetic Data (hereafter, KD) for over 8 years! That re-assured me, because I thought it had been forever…

I also have to admit that I am the oldest person in KD—but of course this does not mean that I am the wisest—as this blog post is proving!

Prior to KD—I can dimly recall that there was such a time—I have been with a number of IT companies working with BMC Remedy and other applications (they do exist), many of which have now melted away like the snow flakes which may be falling outside, when the sun warms them.

So, I hate to admit it, but I have been in this industry for over 40 years, so probably before most of you in this room or looking at this blog post were even in “project initiation phase” and probably before “requirements gathering” and putting out the “RFI or RFP.”

Since then I have worked as a Consultant, Analyst, Designer, Project Manager, Developer, Trainer and even once, on the “Dark Side,” as a Client in this industry of ours.

So, I think I have a right to have a few opinions on this whole “Requirements” business. Hopefully these opinions will inspire some thought, maybe even controversy, and hopefully someone might feel interested enough to have bought me a drink (Single Malt Scotch over 12 YO) to get me to share a little more of my “wisdom.”

OK—here we go.

I was told my Power Point did not have enough bullet points, so I added a second Agenda page. Apart from these two pages, there will be:

NO MORE BULLET POINTS!  JUST PICTURES.

This achieves two things: 1) you might listen, and 2) I don’t have to think of another way to say the same things without using the words in the bullet points.

(For those reading this blog, who want to look at the pictures, someone will have posted my presentation somewhere on the KD website—so you could download it and enjoy the full experience of course, without the “gosh I like the way you Aussies speak” audio component.

Let me “share with you” my first EDP (look it up) job, programming a door opener. I got paid about $50 for it (in those days that would be USD25—now it would be USD60—how the weak become the strong). After the stunning success I had in fulfilling the requirements—door must open, door must stay open for a while, door must close—the requirements were expanded to encompass the concept of “small room – moving up and down in a controlled way,” so I programmed a bigger controller that incorporated all the great work I had done with the  “Project Door” and added moving a room up and down in a vertical shaft, stopping and then doing the door bit. We called this “Project Lift”—or in American—”Project Elevator.”

This was the first time I had been confronted with the idea of requirements analysis in the “real world.” I was obviously excited.

They were simple requirements. We did have a discussion as to whether the doors should open in an “organic, caring and cool way”—it was the 70’s—but we knew that person was a closet hippy, so we ignored this suggestion and just went for “slamming open and slamming shut.” A lot of people nearly lost limbs because of this —but I had the cheque (check) and had moved on to bigger and better things like the Traffic & Parking Infringement Notice system for my home state (Australians have the same urge to make an acronym of everything—that is, when they cannot add an “ie or y” to a name—and we called it the “Project Tin-Pins’.” Yes, there were nerds even in those days and we were they.)

So that brings me to the point of the is session.

How to achieve a successful Kinetic Request project—and—taking a leaf from the “Self Help and Actualisation Movement,” or as I like to call it, “SHAM”the path to success is:

Achieving Oneness with Request ManagementONENESS…

Normally the first interaction you have with any vendor is through the sales team.

Sometimes the interaction is like this…

Over-promise…Get the deal…Under-quote…Under-resource…Under-deliver

At Kinetic Data, we try to make sure that we do not do that.

At the heart of achieving this is ONENESS between the client and Kinetic Data.

INITIAL REQUIREMENTS

Without clearly stated initial requirements everyone is working in a fog of doubt and uncertainty.

Vendors build-in large buffers for this uncertainty and often still under-quote for the project.

Once you have decided on a vendor for your project, work with the internal and vendor teams to:

DEFINE AND REFINE THE REAL REQUIREMENTS

Things to consider when doing this:

  • You may not have all the information; consult widely with ALL stake-holders.
  • There is only  piece of clothing where “ONE-SIZE-FITS-ALL”—a straight-jacket.
  • Trying to combine features of different offerings is rarely a success.
  • Just because it can be done, does not mean it should be done.
  • It may be a solution—but is it practical?

There is a reason why you are initiating this project, and it normally not just to:

  • Replicate the existing application
  • Change the appearance slightly
  • Bolt-on some new functionality
  • Get a more powerful application but restrict it to the old limitations

A successful project should deliver improvement. Not repackage the status quo!

To achieve this, all the parties have to be able to be flexible and willing to change expectations and requirements to deliver the BEST solution within budget and on time.

TIMING, EFFORT and BUDGET

Be realistic. Rome was not built in a day.

If you have been set firm dates  and budget to deliver, then make sure that the requirements are aligned.

LISTEN

We are now in partnership with you to deliver SUCCESS.

It is not a battle between two sides—one trying to get more than agreed and the other trying to do less.

Remember that in a difference of approach, the consultant will advise on the best solution, but at the end of the day—if the client wants it, we will build it.

DELIVERY

So we now have a project that has REAL, WELL DEFINED and ACHIEVABLE requirements.

So, let’s stick with them when we develop the SOW and during the delivery period.

Tacking on new requirements while development is going on does not work. It adds to costs and delays.

Importantly, it just shows that the requirements gathering was a failure.

Finally, remember the ultimate measure of success is the satisfaction of your users.

 

 

 

Last Day of Early Bird Rate for KEG 2013 – Register Today!

Today is the final day of the early bird special for the Kinetic Enthusiasts Group (KEG) 2013 event, to be held once again at the beautiful Inverness Hotel in Denver.

The keynote speaker for this year’s conference will be Eveline Oehrlich, a principal analyst at Forrester Research. Evenline’s areas of focus at Forrester include information technology infrastructure library (ITIL), the implementation of IT service management, business service management (BSM), and many other aspects of IT operations. In this role, she offers strategic guidance to help enterprises worldwide manage their networks and systems, define key projects that focus on IT service management, and bridge IT to the lines of business.

Last year, attendees came to KEG to learn more about products like the Kinetic Task workflow automation engine, get new ideas for use of service requests, and to discuss the future direction of Kinetic Data products.

This year’s conference will feature sessions on moving from a queue-based model to a schedule-based approach for service desks, creating blueprints for service items, connecting service items in a parent-child relationship within a service request, and much more.

Get more details about the event as well as the new pre-event training sessions, and sign up today to take advantage of special pricing for KEG 2013.

Eliciting Requirements for a Successful IT Project

By Greg Johnson

If we built houses instead of technology solutions, would your project sound like this?

Dear Mr. Architect,

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion based on what works for other people.

My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or removed.

As you design, also keep in mind that I want to go green as much as possible. This should mean the incorporation of sustainable, earth friendly materials. (If you choose not to use hemp in the insulation, be prepared to explain your decision in detail.)

I’m sure I can trust your expertise and professionalism. Be alerted, however, that the kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

To ensure that you are building the correct house for our entire family, make sure that you contact each of our children and also our in-laws. My mother-in-law will have strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

Please don’t bother me with small details right now. Your job is to develop the overall plans for the house—get the big picture?

Also, do not worry about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans however, I would expect the blueprint delivered within a week.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. Therefore, it should appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features of this house. Oh, and the turret shaped corner on the front is a must have!

I advise you to look at my neighbor’s house constructed last year. We like it a great deal. It has many features that we would like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on an interesting project like this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can’t happen very often. Contact me as soon as possible with your complete ideas and plans.

PS: My wife has just told me that she disagrees with many of the instructions I’ve given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can’t handle this responsibility, I will have to find another architect.

PPS: Maintenance free is the way to go. i.e., why should I have to turn “on” the dishwasher? Shouldn’t it know when it’s full?

————————————————–——————————–——————————–——————————

Yes, Mr. Architect should run; not walk away from this one but we don’t always have that option, do we? Many of us only have the one customer, so we have to find a way to elicit our requirements in a way that makes the project successful.

Elicit isn’t a common word, but it’s important to use because we are talking about going beyond mere requirements “gathering”. If we only gathered the requirements we would take what is given at face value and start building something. In order to elicit, we must go further to reach a common understanding with the customer that sets the expectations in a documented way.

Start with People

Starting with where this project is coming from, you probably know who your customer is. From there you can identify the stakeholders by asking who is it for, who is affected by it, who will use it, who’s in charge of it and who needs to know about it. You will want to set up interviews with those key stakeholders who have information you need, or have authority to make decisions for others. Interviewing also gives you a chance to identify conflicting ideas and set reasonable technical expectations. Another good idea is to get the stakeholders together for a brainstorming session. This process is a science of its own but the goal is to narrow things down so that everyone is more or less on the same page going forward.

Use Cases

Once you have your input from all the stakeholders, it’s a good idea to walk through the process by documenting informal use cases. Make sure you encourage your stakeholders not to get too caught up in the technology at this point, but to write down each case like a story. Getting people to think about a use case helps flesh out other requirements and refines the business process.

Prototyping

Most technology projects are severely lacking in this area and that’s too bad because it really helps nail down requirements. I suppose it’s because customers don’t want to pay for it and developers don’t want to spend time on something that’s just going to get scrapped later. As a developer, I admit I’m not too keen on it either but consider this—when you have a customer that doesn’t know what they want, this helps them get there. They may need to use the new software (with its associated process changes) before they discover additional valuable functionality and features. If the software itself isn’t available, just mocking up some screen shots might be adequate. Prototyping also helps identify those oversights the customer didn’t include so that they don’t turn up in UAT.  You’ve never had that happen, have you?

Assessing Feasibility

This is a two-pronged review process, which involves both customer and developer.  The customer’s task is to review the business process to make sure the requirements will meet the business goals. At this point it may be useful for them to review their business plan, market analysis, and other documents to determine if this project fits within that framework.

The developer looks at the project’s requirements to see if it’s feasible based on the technology available. It may be necessary to pull in other products or people and make the customer aware of this so they can let go of certain requirements if the cost is too high.

Documentation

Once your requirements are all pulled together, it’s time to write them all down for all to review and ponder. The main purpose of requirements documentation is so that everyone knows what to expect going forward. You and the customer will probably find yourselves referring back to them as the project moves along, so take the time to be thorough and clear. From your perspective, you want to minimize scope creep. If you think of anything that you’re not sure needs to be written down, write it down anyway. Sometimes it’s helpful to also include what things are NOT included so that it can be there for reference later.

Now that you have elicited your requirements, take a step back and reflect on what you’ve accomplished. Do you feel good about it? If so you have laid the foundation for a smart and successful project!

Introducing Kinetic Vision

Kinetic Data is reaching out in support of the Business Service Management community by launching our new blog Kinetic Vision, Building a Better Business Service Management Blog.

For more than 10 years, Kinetic Data has delivered business service management and service delivery management software tools for enterprises and service providers. We build software solutions that allow business departments to interact with employees for better overall service and improved efficiency—throughout the entire enterprise.

Our goal is to empower our customers to take ownership of their service management processes. We are passionate about developing new tools and identifying future trends by listening to you.

Our mission with Kinetic Vision is to provide an objective and informative business service management blog where experts can provide thought leadership and interact with you. Topics will include a wide range of Business Service Management themes.

In addition to me, Kinetic Vision bloggers will include:

  • Derick Larson, Support/Trainer, Kinetic Data
  • Brett Norgaard, Outsourced Service Provider Director, Kinetic Data
  • Greg Johnson, Implementation Consultant, Kinetic Data
  • Michael Poole, Director International Business Development, Kinetic Data

We’ll be posting regularly, so check back often. Grab our RSS feed or subscribe to our blog by email.

Nancy Nafziger
Editor-in-Chief
Marketing Director, Kinetic Data