Why Gmail is Great – It’s Software Developed With the End-User in Mind

Technology in our daily lives is ever-expanding, so it should follow that software development companies are absolutely booming – in fact, MarketLine states that the global software market is expected to grow to a whopping $357 billion dollar industry by 2015, which is quite a boost from the $265 billion total from 2010. Companies already deep in this industry will certainly want an edge over their competition, and there’s no better way to gain the trust of their customers than building great software.

When you think examples of truly magnificent software, what springs to mind? For me, Gmail takes the cake – a simple yet intuitive piece of software that makes the mundane task of writing and organizing e-mail truly effortless. Every aspect of the software is designed to be as easy-to-use as possible, while providing the ability to use a wide array of features. Many times it’s difficult to strike a balance between simplistic design and power, but Gmail hits the nail on the head.

tabs

One thing separating Gmail from the other e-mail services out there is their recent implementation of category tabs. I have to admit, when this feature was released, I wasn’t thrilled – my knee-jerk reaction was something along the lines of “Why complicate things by dividing my inbox? Why fix what’s not broken?” Oh, how young and foolish I was – this feature has quickly become one of my favorite aspects of Gmail, allowing me to quickly jump to different categories. Do I want to check out all of my social media updates? One click of the “Social” tab will do that! How about any promotional e-mails outlining that day’s sales? You guessed it, just hit the “Promotions” tab. Additionally, you don’t even have to specify which e-mail is sorted under which tab – Gmail does it automatically. Brilliant!

If you’ve ever mentioned attaching something in Gmail, and then completely forgot to attach it, you’re greeted with the following message:

attachfiles

This likely didn’t take much time to develop at all, yet has likely saved many people from looking foolish (first-hand experience here). While it isn’t likely to make or break which e-mail service you choose, these details really impresses you when you need them.

It’s this kind of usability that gives me confidence in Google’s software – I’d be more willing to try software that they develop, since I’m comfortable with the kind of work they do from prior experience. On the flip-side, had my Gmail experiences been full of frustration or lacked the features that I’ve come to expect, maybe I’d check out alternatives – in fact, it was my frustration with Yahoo!’s services that led me to leaving it behind in the first place. The bottom line – usability matters, and if you aren’t able to put out simple software with powerful features, your customers will find someone else who can.

Advertisements

Mirth Connect – Not Just HL7

Mirth Connect is an open source application used for healthcare data integrations, specifically designed for HL7 interfaces. It is widely used for transfer of health data between two parties in an order to results cycle. But what happens when you need to transfer data to another party who isn’t using an HL7 interface? Limiting your inbound/outbound capabilities to only the HL7 format may prevent adding new customers. But, adding a second interface/solution may not be worth the cost of adding the new customer. The need to invest in a second solution is resolved by the different Connector Types available within Mirth Connect.

In this post, I am going to show you an example of how to interface HL7 data to a Web Service. We implemented this back in 2012 for a client. Our client had an existing HL7 interface and was receiving HL7 orders, processing the claim, and sending back HL7 results. They had a potential customer also looking for an electronic data transfer. However, they were not using HL7 formatted data. The potential customer used an application that received data via a secured SOAP request. Because this was a single client, it was unlikely that building a separate interface specifically for the integration would be the best business decision. So, we explored the possibility of using existing functionality (Mirth Connect) to send data to this web service.

Mirth has the ability to transform data between multiple formats. In this case, we were able to use the JavaScript writer to take the necessary data points (via Source Transformers) and complete the proper SOAP request. While Mirth Connect offers a Web Service Connector Type, we found the best flexibility in the JavaScript writer, where you can customize all the functionality and you are not limited by the default behaviors of the template.

Check out our example below, and find more information on Mirth Connect here: http://www.mirthcorp.com/products/mirth-connect

// open a connection to the Web Service
var url = new java.net.URL("https://testinterface.com/Document.asmx");
var conn = url.openConnection();

// set the connection Timeout
var connectTimeout = 30000;

Here we are returning the XML from our Source tab under the Transformers. This isn’t the only way to do it, but this worked best for us and our current solution.

var messageString = messageObject.getEncodedData();

You could also do something like this, where you build out the Request XML and use Transformer variables that you include as XML Node Text

var messageString = "<SOAP:Body><Patient>" + messagePatient + "</Patient><MRN>" +  messageMRN + "</MRN></SOAP:Body>"

conn.setConnectTimeout(connectTimeout);

Here we needed to use Request Headers, which we found easier to setup in the JavaScript writer than the Web Service Connector.

conn.setRequestProperty("ID", "123");
conn.setRequestProperty("USERNAME", "ALGONQUIN");
conn.setRequestProperty("PASSWORD", "PASSWORD");
conn.setRequestProperty("Content-Type", "text/xml; charset=utf-8");
conn.setDoOutput(true);

// Write our XML data to the Web Service URL
var outStream = conn.getOutputStream();
var objectStream = new java.io.OutputStreamWriter(outStream);
objectStream.write(messageString);
objectStream.flush();
objectStream.close();

var inStream = new java.io.BufferedReader(new java.io.InputStreamReader(conn.getInputStream()));

Consistency is Key!

A successful software development project is one that maintains consistency.

Whenever I visit a site or application that lacks consistency, it makes me uncomfortable. If each page acts differently from the others, it can end up confusing the user and feeling and looking poorly developed and unprofessional. A good development coding standard can help ensure a high level of consistency throughout an application and, once in place, these standards need to be followed. In the end, a good developer needs to make sure his/her final output reflects the standards and is built in a consistent, user-friendly way.

Another reason to adhere to a consistent, standard approach when developing a new application? Without it, the ongoing maintenance of the application will become cumbersome. If five developers are all coding differently, in their own style, you’ll eventually end up with an application that won’t lend itself to easy maintenance and might not function properly in the long run.

Remember, software often ends up being maintained by people who weren’t involved in the initial development of it! If you’ve ever been responsible for the upkeep on an application that was built with little adherence to quality standards, you know—it’s no fun! If the cost to upgrade or improve an inconsistent application becomes too high, it could force the client in a different direction.

I remember supporting an old ASP 3.0 application that was generally using the same connection information in a standard configuration file but had a few forms using hard coded values for the connection information. I couldn’t understand why, all of the sudden, some of these were breaking when my database information changed. This should have been a quick change to the configuration file, but turned out to be a pain!

When building front-end user interfaces, make sure you’re putting on your “end user” hat before you start working. When building out forms, do so in a consistent manner. If you have grids with search results on a screen, make sure all those grids are reporting the same data, and the same options, in the same way. Make sure all dates are displayed in the same format. All numeric/monetary fields should display consistently. Buttons with the same underlying logic should have labels that are consistent so the user can understand, from screen to screen, that button does the same job or accomplishes the same function. Make sure your form controls are organized in a pleasant manner—one that’s easy on the eyes and that can be tabbed through quickly. If it’s a data entry screen that users will be spending hours on each day, make sure the controls are aligned and sized properly allowing users to keep their focus on one part of the screen and providing a better overall user experience.

Before you start developing, take a look around! Review some of the screens in the system—there should be a common theme to the user interface; follow the same approach. Take a look at messaging and make sure you’re reporting information to end users in the same way. It won’t take long to get familiar with the site and then, once you start building your new feature, you’ll have a good context as to what it should look like. When you’re done developing, the new feature should look like existing ones.

One last note when testing your development—people still use IE! Do some browser testing to make sure your site is looking good and functioning well in the major browsers. If you’re only developing and testing only in your personal favorite, you’re not doing a full test. Sometimes, there are specific client requirements for the system you’re working on, so be sure you know what they are before you start. Some internal applications are written strictly for IE. Are there mobile requirements for this application? If so, be sure you’re testing those as well.

In the end, making sure your software development is done in a consistent matter is better for everyone in the long run. It will ensure the end product looks and feels like a well thought-out, professional piece of work!

Why Software Developers Make Good Spouses

 I often envy my wife because she married a software developer. She doesn’t realize how lucky she is! Come to think of it, I think everyone married to a software developer should applaud themselves for their wonderful choice.

Why am I being so boisterous about the idea of software developers as an ideal spouse?   I can give you thousands of reasons but, unless you’re a developer yourself, you probably won’t have the patience to read them all. So, I narrowed it down to the top 5:

 1.  They don’t mind being nagged:    

Developers like to build alerts into their software. Alerts to call them, text them, or interrupt them with a popup message.   They want to be alerted when something goes wrong, when something unusual happens, or simply, when the software completes a step. They build these alerts because they care and they love to be told when something needs to attention. So, if you are married to a software developer, nag away. If you are looking for a suitor and would like someone who won’t mind being nagged, narrow your search to developers only.

 2.  They like being told when they are wrong:  

Developers always like to trap for errors. They don’t rest until their software takes care of every possible error. They also make sure they log every error that occurs. No, it’s not that they love their mistakes. As I mentioned above, they just want to know if something went wrong so they can attend to it. If you have uncontrollable urges to tell people when they’re wrong, you should definitely look for a software developer as your life partner. Even if you’re just a casual observer who happens to have a keen eye for spotting mistakes, you should only look for software developers when searching match.com

 3.  They want to keep improving:

Developers love to release new and improved versions of their software. They feel obligated to add new features and improve existing functions and they usually release these new versions on a self-imposed cycle. If there’s nothing to improve, they’ll find something, even if it’s just updating the “look and feel.” Wouldn’t you love to have a spouse who wants to keep improving? Improving how they behave; improving how they look? It’s like marrying a “6” on a scale of 1 to 10 and watching them become a “10” in few years. How could you resist a prospect like that?

 4.  They know how to use all the new electronic gadgets:

Developers don’t shy away from switching to the latest smart phone. And they don’t hesitate to buy that new smart TV or replace that old computer. You can have the latest and the greatest gadgets just because you married a software developer! You’ll be the coolest kid in your group of friends! Go ahead…Brag about having all your music and videos in “the cloud” and being able to access them from your phone, tablet, home computer, work computer, TV, and even your new multi-function wrist watch. You’ll be as tech savvy as you want (and then some) with a software developer as your significant other. Are you one of those people who wanders around looking for an available computer you can check email or Facebook on? Stop wasting your time and marry a developer already. You’ll be connected, informed, and up to date, 24×7.

 5.  They can think…And they actually like to:

Don’t you just cringe when talking to someone who uses blunt phrases in response to your well-worded, profound statements? It’s the worst! If you like responses that are well thought-out, fully explained, and logical then you should limit yourself to only conversing with software developers. They’ll always give you precise, detailed answers and will be able to quote facts to support their opinions! Developers love Googling for answers (of course, we do…Google was built by developers!). If you overhear someone at a party proudly brag that their spouse “knows it all” you can bet they’re married to a software developer!

Live happily ever after…

I’m sure you can now can see what a wonderful life that awaits you if you choose to spend yours with a software developer. If you’re young, eligible, and smart, don’t settle for a boring business person, banker, fashion designer, athlete, or super model–find yourself a software developer and you’ll live happily ever after. Just ask my lucky, lucky wife!

Project Management & Relationships

Very often our blog contributors post great articles about things like managing expectations, solving problems for our clients, and gathering requirements from a client. All of the articles touch on topics that are very relevant to the work we do as consultants every day and one of the key aspects of doing each of these things well and, in turn, being good consultants, is to develop strong relationships with our clients.

Learn About the Key Players

When setting out on a project, one of my goals is to gather the requirements of the software that we’re being engaged to build. Beyond that, we need to understand who the decision makers are. These are often the people that we’ll being dealing with regularly to get things accomplished and make sure the project doesn’t stall due to indecision or missed deliverables. From the smallest task that requires a simple yes/no answer to a very important meeting to discuss a pivotal system process, as Development Managers, we’ll regularly engage the key decision makers to get all the necessary tasks completed.

As part of building a relationship with the parties involved in a project, we’re always trying to understand how our software will help their business. Clear communication is important to any project and we’ll often need to go the extra step of learning the company or industry-specific terminology that our clients use on a day-to-day basis. This helps us understand requests and communicate with each client most effectively.

Another important thing to learn about key parties for a project: what forces are driving their requests, decisions, and actions? From the start, we need to try to find what will make the project run smoothly and what could potentially hold the project back. Key questions here will cover topics like target dates, project budgets, and critical processes. These questions and their answers will help us do exactly what many of our other blog posts talk about–gather requirements, manage expectations, solve problems–all of which are crucial to the success of a project.

Row With, Not Against, the Third-Party Stream

What if your project requires you to work with someone in addition to your client? As a software development team, we regularly find ourselves in situations where we’re required to work with other vendors on tasks like integrating with other systems, adding/modifying code that isn’t ours, or working in an environment that we don’t have control over. These things can present potential hurdles, but we strive to do the best we can to navigate these waters because that’s what will make for the best possible experience and solution for our clients.

Much like when you’re building a relationship with a client, you’ll want to find and engage the key players of any third-party vendor and learn how best to work with them. Some of the best ways to ensure a friendly and professional relationship that meets the needs of your client and their project include:

  1. Asking early and often – If our development team needs something from a third party, whether it be access to a system or knowledge of existing code, we’ll do our best to get ahead by asking questions again and again, as soon as we know we’ll need the assistance.
  2. Understanding that third party teams have schedules, too – People often overlook the fact that other teams are fighting to meet their own deadlines outside of the project you’re working on together. We find the best way to stay on top of external deadlines is to repeatedly ask for tentative completion dates or turn-around timeframes from our co-vendors, so we can align our own goals and expectations and help better manage the goals and expectations of everyone involved in the project.
  3. Smiling – It sounds cheesy, but it can help. If you’re getting resistance from an outside party, do your best to smile when pushing for the answers you need. The best case scenario is that you establish a genuinely friendly relationship with your co-vendor but even if you don’t, getting the answers and info you need in a pleasant manner is always going to make it easier for you to work together successfully. And always remember to keep your client in the loop if you’re waiting for answers or status updates from another vendor.

Does Your Client Look at Your Development Team as a Partner?

As a developer, I often find myself in conversations about how people use applications, even outside of business hours! I frequently get the same feedback from friends/family that I do from new clients–they feel like the people who work in development (or “IT”) abandon them as quickly as possible. In developing good relationships with your client, make an effort to communicate that you’re “with them” on their project. The difference in saying something as minor as “We’ve accomplished” vs “I’ve accomplished” can have a big impact on that feeling. At Algonquin Studios, we take pride in being with our clients and doing the kind of relationship-building work discussed above gives us an extra sense of pride in what we’re able to accomplish. And, we hope that shows in all of our interactions with our clients.

The Corporate Dashboard

In this post, I’d like to talk about the good fundamentals of dashboard design. There’s an important item that separate a bad dashboard from a great one. It’s called a “Key Performance Indicator” or KPI. When we discuss KPIs, we are usually talking about something like “Income forecast” or “Employee productivity rates.”

The most important part of the KPI acronym is the “K” for “Key.” Key means it’s supposed to be important but all too often, I’ll hear:

“I want a dashboard with 50+ KPIs that can quickly show me the health of my company at a glance.”

Remember, the “K” stands for “Key.” Do you really need more than 50 indicators to “quickly” show the health of your company or department? Are there really 50 plus things that are “key” to your review? Can you even review 50 of anything “at a glance?” Really?

As an example, let’s take a look at a “Dashboard” with only a few KPIs versus one with lots of KPIs and see which is better suited to give us an “at a glance” view of the status of our company:

While each of these dashboards shows information that’s likely very important to the user and the health of the system, there’s an obvious difference in the amount of information being displayed and each is intended for a different kind of user.

The first is clearly a dashboard from a plane, specifically a B-58, and it has a ton of indicators and gauges. This type of dashboard can certainly be overwhelming to someone who’s not a pilot and hasn’t undertaken the significant training needed for its effective use. Now, this doesn’t mean there are too many KPIs on the dashboard, it just means that the process that the user is attempting to navigate is very complex and requires a high level of expertise. It would not be expected that someone viewing the dashboard would be able to tell the status of the plane in “at a glance.” If you really dug into it, there are probably only a few “Key” indicators on the board and lots of additional indicators that will help the pilot track specific information, look for particular problems, or do their job in emergency situations.

The second dashboard is from a BMW M series. It has two large dials for the Speedometer and the Tachometer and a few indicator lights for important factors like “Door Open” or “Check Engine.” This type of dashboard requires a much lower level of training to understand and interpret and only offers KPIs that tell the user how the car is performing in its primary objective–moving–and if there are any significant problems like a lack of gas or increased oil temperature. And it’s pretty important to realize that your car door is open when you’re driving along at 60 miles per hour! There are hundreds of other metrics that could be useful to different users (i.e. the car technician or the racing enthusiast) but they’re not “Key” performance indicators needed to simply drive the car and they can be retrieved in other ways.

Now, both of these dashboards accomplish their goal of providing all of the information that the user needs at their fingertips. But as I’m sure you could guess, the B-58 dashboard costs a lot more, because it’s more complicated in its design, its build, and its output.

If you’re considering building a dashboard, you must start by defining who your audience will be and what information they’ll need “at their fingertips” to be successful. Most dashboards only need a few metrics/gauges; the bulk of the effort should be spent on important things like that “Oil Temp” light. Define the rules to indicate that there are problems and then allow the dashboard to work for you. 

In an effort to collect some input from the readers, please comment below if your company has a dashboard. How many KPIs do you think are enough?

4 Questions a Software Developer Should Ask Each Day

This is my take on a lesson I was taught very early in my career.  It made sense to me right away, but after applying it for over a decade I’m convinced its one of the most important things I’ve ever learned.  I hope to do it justice in sharing it with all of you.  I’ve written this from my perspective as a custom software developer and consultant, but I believe it applies universally to software developers.  If you’re an in-house developer, just think of your clients as the folks you build software for (i.e. the users, your managers and the owners, etc).  Start by asking yourself:

Question #1: Is your client happy?

This should be the first thing on your mind at all times.  A happy client will come back for more. They’ll tell their friends about you.  They’ll promote your brand.  They’ll keep your pipeline full.  Clients are your lifeblood and keeping them happy is the only way to survive long-term.  I know… this is obvious, right?  Well, it’s not that easy to execute on all the time and a lot of developers don’t really understand what it means.  We’re not looking for short-term happiness brought on by just doing whatever they ask or by applying quick fixes in difficult situations. We’re after long-term, sustainable happiness.   How can we achieve that?

Manage Expectations:

This is huge.  You have to start managing your client’s expectations the moment you meet and continue doing so throughout the course of the relationship.  The moment you stop filling their heads with facts, they’ll start filling it with all types of other things.  Expected timelines will creep, visions of features will morph, old conversations will take on slightly skewed meaning in the light of new information that isn’t shared and wasn’t part of the original conversation. Expectation creep is not malicious… its human nature.  Small expectation gaps are like a crack in the foundation of your house.  With effort you can avoid them in the first place, but if allowed to form and grow they can be devastating to a relationship.  Communicate clearly, completely and often. And memorialize EVERYTHING in writing.

Honor your commitments:

Lots of promises are made at the beginning of the job.  Most of them will be recorded in a contract that commits you to honor them. However, not every intention, notion and promise will make it in there.  There will always be a new way to look at a deliverable later on and re-interpret its meaning. This tends to happen when the going gets rough. Maybe things are taking longer than anticipated. Maybe you’ve had staff or personal issues that distracted you from the project.  Stuff happens.  Renegotiate the terms if it’s reasonable to do so, but don’t, under any circumstances hide behind a nuance in the contract language or try to back away from the original spirit of the deal.  You know what you committed to. Honor it and get the job done. It will hurt at times, but your client’s happiness and your reputation depend on it.

Be a partner:

You’ve agreed to help your client solve a problem.  The best way to do that is to look at the issue as your own.  Do your best to see and feel the goals from your client’s perspective.  Own the problem.  Your client can tell the difference between this approach and that of the last firm who was just “doing their job”.

Be Available:

You should return calls/emails in a reasonable and consistent amount of time and you should answer the questions contained in them.  If you take long, random amounts of time to respond you’ll frustrate your clients. If your late response doesn’t answer the question, you’ll infuriate them.

Stick to your principles and do the right thing:

Your client hired you because they don’t have the time, or more likely the expertise to accomplish the task.  Even though you’ve been brought in as the expert, there will come a time where the client insists you to do something that you know will hurt them in the long-run.  It’s your duty to hold your ground in these situations. Take time to explain why this approach will be harmful. Give examples. Be steadfast. Ultimately it’s their decision, but you owe it to them to try and do the right thing.  I often liken this role to that of a personal trainer.  If your client came to the gym and told you they were tired and didn’t feel like working out, you could satisfy their short-term desires, buy them a muffin and a shake and plop them in front of the TV for a little Judge Judy, but that’s the easy way out and it won’t help them accomplish their long-term objectives. It’s your job to get them motivated and on the treadmill.  Don’t be a coward… do your job!

Be enjoyable to work with:

Make a connection with your clients on a personal level.  Ask them about their kids, their pets, their hobbies.  Be human and have a sense of humor.  Your client will like you if you help them solve their business problems.  They’ll love you if you help them have a good time doing it.

Be humble:

I’ve already stated that you’re here as an expert, but that’s probably only true for your specific role in the overall initiative.  Whether you’re building software or developing a social media strategy, you’re doing it for them.  Don’t come in acting like you’re the savior.  Do your part and do it well, but trust that they understand their business better than you do and they have the grand vision.  This is a learning opportunity for you and it’s probably the best part of being a consultant.  Listen intently, learn from them and make sure they know you’re doing it.

Question #2: Is your work correct?

If you’ve executed on the principals from #1, your client’s in a happy place.  Now it’s time to deliver and your solution better work.  It must accurately achieve the goals of the project in a meaningful and sustainable way.  It has to work today so that they can execute their business plans and begin to see some return on investment.  It has to be flexible enough that it can be modified as their business evolves.  It has to be scalable so that it will remain viable as their business grows.  Ultimately, this becomes an extension of #1.  Your product speaks for you when you aren’t around and it should continue the good work you did from the beginning.

Question #3: Is your work on time?

So you’ve got a happy client and a solution that works.  Next, you need to ensure that everything is delivered on-time.  Every project you take on becomes part of some larger business plan.  Once you commit to timelines, your client begins to plan their next steps.  Let’s say they’re planning a major product launch to coincide with the release of the new web site and online catalog you’re building for them.

They’ve got billboards going up, commercials ready to air and an army of trainees preparing to handle the expected influx of business…. and it all hinges on that end of year delivery your promised.  Now imagine its mid-December and you tell them you won’t be hitting your date.  It’s a client happiness catastrophe!  Months of planning is coming unraveled, your client cancels holiday bonuses for their staff because they need to conserve cash to pay the army of trainees with no corresponding revenue offset, they can’t cancel the billboards and commercials and they’re going to look like fools when they don’t deliver the product their hawking; oh… and your client is really starting to worry because they have a family vacation planned for the month after the project was set to be done and now that’s in jeopardy.  This may be an extreme example, but rest assured that your missed deadline will cause problems for you client that you may never even know about.  All you’ll know is that despite “everything you’ve done for them” your competitor wins the next job.

Question #4: Is your work on budget?

I bet you didn’t think it’d take this long to talk money.  Don’t get me wrong… budgets are important, but less so than client happiness, quality and timelines when it comes to your long-term success.  Simply put, you must never sacrifice #’s 1-3 to keep your budget in line.  That’s short-term thinking and it’ll eventually lead to a crippling pile of problems that will crush your business and reputation.  In a recent post titled Keeping Projects on Budget, I explained how an end-to-end project management effort is required to walk this line.  You’ll need to develop a process that works for you and execute it flawlessly.

One key topic to keep in mind along the way: Don’t do Out of Scope work for free!  I mean it… never ever ever ever. Not even small stuff.  Given the flexible nature of software, it’s easy to throw in this tweak or that additional feature.  It seems harmless at the time, but it always leads to problems.  First off, you’re mismanaging expectations.  You’ll be more likely to agree to something extra at the beginning of the project when you have lots of budget then you’ll be at the end when the budget’s winding down.  When you say yes, yes, yes then no, your client starts to feel cheated.  Why are you tightening the reigns now?  This leads to unspoken animosity where the developers think their earlier “generosity” is not appreciated and the client thinks this new strictness means the development team isn’t willing to see their “promises” through to the end. Everyone’s right and everyone’s wrong. It’s a bad situation and it damages relationships.  Secondly, now you’ll have to finish the scoped items with less than the necessary budget. You’re faced with sacrificing quality or sacrificing your profits.  That sucks.  See #2 for advice on what to do.

Summary

Software development can be a tricky business.  Most developers can handle the technology, but many struggle with managing the overall process.  Ask yourself these questions daily and align your efforts with satisfying them in priority order.   It takes time and effort, but if you persistently follow this list you’ll build great relationships, feel good about the work you do and eventually… you’ll make some money too.

I’m always looking for new tips and techniques for keeping my clients happy.  What’s worked for you?

Recommended read: While researching for this post I came across an article I liked so much I had to share.  A short, but important read: Mastering Account Management: 5 Tips for Keeping Clients Happy

Self-Help and What It Means to the Future of Customer Service

Self-help–it’s the sort of thing that everyone wants to be able to do in order to be the most efficient they can be without having to bug someone else or take more time out of their already busy day to track down assistance.  Self-help is becoming the norm in everyday customer service, across many different technology platforms.  But, the question that has yet to be answered is, will the general public accept the self help model of service?  The answer is, if implemented correctly, yes, because it will increase productivity and make customers feel empowered–able to assist themselves without having to ask anyone else for guidance and without having to wait around for answers or instructions.

I can’t tell you how many times I have heard people complain about having to speak to a Help Desk representative because they often sound like they’re just reading from a script, giving no real advice and providing no real insight. Experiences like these offer very little to instill confidence in a customer about the level of service they’re receive.  By giving customers the option of self-help, we’re putting them in the driver’s seat. They can resolve issues for themselves and feel the pride that’s inherent in fixing something on their own.

Support professionals need to be creative in identifying and creating opportunities for customers to embrace the self-help style of customer service, though, in order to encourage the mainstream adoption of the model. Successful self-help relies on detailed and well-informed knowledge base articles, how-to videos, and tutorials. Compiling lists of frequently asked questions is a great place to start–

If we approach development projects with consideration for where we can build self-help options into the software we’re building, we can make it easier for our customers to use and experience the benefits of our solutions. Finding opportunities to place a link or a button that provides immediate access to knowledge base articles that offer step-by-step procedures on how to fix issues are a great example: tutorials and how-to videos make it much easier for users to “see” the application in use, instead of having to read through steps which might be confusing to some. Identifying ways to incorporate both options, like the use of new “multiscreen” software built into many new Samsung phones and tablets, is fantastic because it gives the user the ability to view the help documentation while walking through the necessary steps in the app at the same time.

As developers and support representatives, we need to keep in mind that, the more we can successfully integrate self-help features into the software we build, the more value we’ll provide to the customers using our solutions and the easier it will be for our customers to stay on task without getting waylaid or frustrated. In a society where time is money and instant gratification is expected, this value can’t be overlooked.

Keeping Projects on Budget

BudgetYou know the drill.  Some ridiculously high percentage of software projects go over budget… And you’ve heard stories to back it up. Or worse, you have your own tales of being hung upside down by your ankles while the developers shake you down for every last cent.  Yet, here you are.  You’ve got a problem and it seems the only solution is custom software.  You’re doomed, right?  You might as well get ready to grin and bear it as you’re no doubt about to head down a path of endless pain and misery.  How did it ever come to this?

It doesn’t have to be this way!
I know… suspend disbelief for just a minute.  It’s going to take a lot of planning, coordination and hard work, but a well-executed software project can stay on budget AND deliver you a solution that satisfies your objectives in an effective and lasting way.  Here’s how we’ll help you do it:

Initial Sales Meetings and Preliminary Requirements Gathering
We start every engagement with an open mind. It’s important to fully understand all of the issues and goals before committing to any particular solution or technology.  Our initial meetings are designed to learn about your business and the issues you face.  What are the specific problems you are trying to solve and what are your goals?  Essentially, we start by helping you to define what success looks like for your project.  With that understanding our team will draft preliminary recommendations and deliver those with ballpark estimates.  At this point, we still won’t have all of the knowledge required to solve your problems, but we definitely have enough to determine if we are in the same ballpark… that is, determine whether or not we should continue before you spend any money.  If we are, the next steps will be to propose a formal Requirements Analysis process.

Requirements Analysis (RA) Phase
In this phase you’ll formally define what we are going to build.  We’ll schedule a number of meetings (preferably face-to-face) where our staff will spend time with your team to define the nitty-gritty details of the project. We’ll ask questions… I mean A LOT of questions.  We‘ll gain an understanding of your workflows, your staff, your business cycles, etc. so that we can clearly identify all of your needs.  With this deep understanding, we’ll produce several outputs that will help you effectively solve your issues within a predictable budget:

  • Business Requirements Document (BRD) – This is a comprehensive, plain-English, easy to understand definition of what you’re asking us to build. It can be read and understood by anyone on the project team, regardless of technical ability. The BRD is the cornerstone of the project and plays a fundamental role in sending you down a path where a predictable outcome and budget is possible.
  • Screen Mockups/Wireframes – These will provide a roughed-out visual representation of the system. They will help you to gain a better understanding of how the system will look, flow and feel.
  • Flowcharts – These are a visual representation of the workflow and business rules for the more complicated sections of the system.  They will help to further iron out the finer details of the project and identify “holes” early on.
  • Fixed fee for implementation – Once we know exactly “what” we’re building, we can very accurately predict how long it will take and how much it will cost.  That allows us to provide you with a fixed fee proposal for implementation.

In addition to these outputs, we will provide you with guidance on infrastructure needs, licensing for 3rd party components, and requirements for any 3rd party vendors, plus details on what your team will need to do to keep everything on track and make the project a success. Getting all of these issues on the table early and working together on a plan for dealing with them is the most important step towards a path that allows for a predictable budget.

The outputs from RA are yours to keep and are designed in such a way that any development shop with the appropriate technical abilities could implement them for you.  We certainly hope that you’ll choose to continue working with us, but at this point you are free and clear to move on if that’s what ‘s best for your organization.  And the best part… you’ve likely gotten here in less than 20% of your overall project budget.

Implementation
Once you agree to our fixed-fee proposal we’ll begin to implement your solution.  As far as the agreed upon scope is concerned, you won’t have anything to worry about in terms of budget.  We’ll produce the agreed upon output for thee agreed upon fee.  However, there may still be other costs that need to be managed.

Out of Scope (OOS)
We’ll continue to spend a lot of time with you during the implementation phase.  In particular, we’ll have regularly scheduled demos and walkthroughs that will allow you to see, feel and tweak the system throughout the process.  Minor adjustments to layout, appearance, terminology, etc. are expected and this is taken into account within your fixed fee.  However, you will inevitably identify additional opportunities for enhancements/changes that were not thought of during the RA phase.  Many of these items will be relegated to a future phase, but some may represent such a benefit to your solution that you choose to implement them now.  We’ll tap our vast project experience to help you classify the items and advise on how to best fit in those “must haves” with minimal impact to your timeline and budget.

Third Party Vendors
Very often you’ll have additional vendors that play roles in your solutions (i.e. your IT staff, your hosting company, the firm that supports the application you have asked us to integrate with, etc.).  This can create pressure on timelines and that can have an impact on your true costs (even if just by requiring additional time investment by your staff).  We’re very experienced in dealing with these situations and will advise you on how to get commitments from these parties and hold them accountable to meeting them.

Adoption
Once your software is complete, you need to get your users to use it.  This involves training, planning cut-overs, etc. and these things can definitely impact your true costs for the project. Having deployed hundreds of systems into organizations of all sizes under a wide array of circumstances, we’re able to advise you on a roll-out strategy that will help this all happen predictably (and on budget).

Quality Assurance (QA)
Your project has been in QA since the RA phase. Our QA team is tasked with reviewing and approving your Business Requirements before implementation can begin.  Then, the QA process continues through implementation with Code Reviews and internal screen reviews. Finally, the resulting software is put through a rigorous final QA pass that verifies all of your business rules and may include load tests, security scans, etc.  How does this impact the budget?  It’s all included in the fixed fee, but the value goes beyond that.  By ensuring a quality product goes out the door, we’re really enabling you to predict the long-term operating costs of the solution.  That will keep you “on-budget” for the long haul.

Ongoing Support
Depending on your specific situation, there’s a very good chance you’ll need or desire some level of support from our staff post-go-live.  With a full-time help desk and available 24x7x365 support solutions, we are equipped to provide you with a long-term support arrangement that meets your budget and business needs.

Deployment
Once everything is done, we still need to launch your software before you can start using it.  Delays of any kind will likely impact your total costs (i.e. think costs associated with preparing your staff for a launch that doesn’t happen, then doing it all over again a week later). Our development process takes a structured approach to this as well.  With thorough checklists in hand, our staff will be able to launch your software on schedule and will be less likely to run into last second “surprises”.

Summary
Our development process has been defined and tuned over the past 15 years through the experiences gained in thousands of engagements.  Our comprehensive approach, combined with the vast experience of our staff, allows us to identify and address hurdles early on and helps to eliminate the big “surprises” that plague so many software projects.  This allows predictability… And predictability saves budgets.

Finding The Best Technology Solution Shouldn’t Feel Like Herding Cats

The Value of Requirements Analysis

Sometimes it’s hard to remember that “problem” isn’t a dirty word. Your business solves problems every day; that’s why your customers come to you. Let’s start thinking of problems, not as bad things, but as opportunities.

Imagine that you’re considering a new line of business or you’ve found a process that causes a lot of friction, so you decide to change. You’re probably anxious and we can understand that; there are lots of ways to get off course when you charge a team with change:

  • Each team member goes after a different problem, so the solutions don’t converge. How do we get everyone back on the right page? What is the right page?
  • The project keeps growing and growing. As the team starts solving the problem, you find people adding new features to the solution. The team keeps looping back to revise the plan and each time you do, your budget grows. Nobody saw this coming. How do you stop it?
  • The team implements a solution. A few months go by; you analyze the data and find that the problem is still there. What happened?
  • The team proposes a solution. Senior decision makers hesitate because of budget, lack of in-house talent, or other priorities. Without buy-in, decision makers cancel the project. Does this mean you have to start over?
  • The team recommends a product to fix the problem. But once the product is in place, you find out there are some critical gaps in the solution. How can you bridge these gaps?

Here at Algonquin Studios, we have a process that prevents deviations like these. We call it “Requirements Analysis.” We begin by defining the core problem. We dig deep. We’ll humbly challenge your team by asking “Why?” and we won’t let you down by accepting the first answer as gospel. If there’s more than one problem, that’s OK; we’ll prioritize them. Working together, we’ll define exactly what your problems are and ask your whole team to commit to working on them.

Next, let’s propose solutions — lots of solutions. Don’t limit yourself to technology; you could change people, processes, and policies, too. After brainstorming, we’ll cull ideas together and judge our good ideas by doggedly adhering to the problem definition. A vision should surface — a vision of what your firm looks like operating the solution. You’ll feel good about committing to this vision and we’ll return to it again and again to overcome anticipated barriers and engage your team.

Now you’ve got a defined problem that’s simple to communicate and a vision for its solution. Algonquin Studios finds that these two key ingredients give you clarity, keep your team focused and gaining ground, and can nearly eliminate re-work costs from here on out.

After working through the initial Requirements Analysis (RA) phase detailed above you may determine that you need a new process, and some tools to operate it. By applying our detailed RA process at this stage, we can capture all of the business rules, inputs, outputs and processes to build or adapt those tools while honoring your decisions about scope, phases, and value trade-offs. We’ll start at a high level and break apart complicated processes until we reach simple, atomic ones. A solid detailed RA document becomes the foundation for planning, designing, building, deploying, and training for a good solution.

You might be surprised to find that a policy change is all that’s needed to solve the problem, so there’s nothing to build. And that’s a fine outcome!

We know this sounds potentially uncomfortable and like a lot of work. As a decision maker, you’re already living and breathing your problems every day and are hoping for a vendor to simply roll out the solution you’ve already got in mind. But what if there was a better way? A way to help make sure your solution is an unprecedented one that can grow your business like never before. That’s what we believe the RA process is, and it’s why we’re so committed to it here at Algonquin Studios.