Connecting Business Applications with Mobile Customers via Twilio’s SMS Service

In the constantly changing and ever-growing market of mobile technology, businesses face the challenge of finding methods to effectively communicate and connect with their target customers who are always on the move.

In this post, I’ll outline how you can integrate Twilio’s SMS service into a .NET web application in a few simple steps. We’ve recently integrated Twilio into a client’s web application as a means to communicate with employees after-hours, when employees have left for the day but a situation arises that needs further attention.

Before we get into the coding, let’s take a quick look at other methods that are used to send SMS messages from applications.

Email-to-SMS Gateway functionality has existed for a while and offers some of the same benefits, but with a few caveats.

  1. What if you don’t know the customer’s carrier? You need this in order to utilize it (for example, if your customer’s number is 555-777-8888 and is a Verizon customer, you can text them by sending an email to 5557778888@vtext.com)
  2. You cannot control who the message is sent from, for some carriers is the email address of the send, for some it’s the email address of the server
  3. You cannot control what number delivers the message, so the customer may not be able to respond back to the message

Twilio’s SMS service overcomes these hurdles in simplistic fashion. Twilio’s SMS service allows web applications to communicate with mobile customers with a few simple lines of code.

Let’s get started. First, you’ll need to add the Twilio service into your project by following these steps (note that this is for .NET 4.0 application). The installation process can be found here: https://www.twilio.com/docs/csharp/install

Once you’ve installed the service, you’re ready to add your SMS code.

In this case, our function is setup to receive a Phone Number that we are going to send a message and the Body of that message.

Public Sub SendSMS(ByVal receivePhoneNumber As String, ByVal messageBody As String)

Dim accountSID As String = ""
Dim authToken As String = ""
Dim objTwilio As Twilio.TwilioRestClient = Nothing
Dim objMessage As Twilio.Message = Nothing
Dim sendPhoneNumber As String = ""

When you sign up for your Twilio account, you’ll receive the following credentials within their application.
authToken = "111111"
accountSID = "222222"
sendPhoneNumber = "5553211212"

Instantiate your Twilio object
objTwilio = New TwilioRestClient(accountSID, authToken)

And send!
objMessage = twTwilio.SendMessage(sendPhoneNumber, receivePhoneNumber, messageBody, "")

End Sub

So now we’ve sent our message. It’s sent to the end user via a telephone number, just as if you were sending a text message from your phone. What if the end user wants to respond back? They can, with no additional effort on their end. The message will be sent back to the Twilio number, and Twilio will redirect the response to your web application.

Within the Twilio client, you can setup a Messaging URL, which will define where Twilio POSTs the response to (for example , http://www.yoursite.com/receiveTwilioResponse.aspx). Let’s setup that page.

When we setup receiveTwilioResponse.aspx, we’ll need to capture the Page Request and parse out the response message.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

Dim fromPhoneNumber As String = ""
Dim messageBody As String = ""

First, we’ll get the Phone Number of the end user who is responding back to us
If Not Request.Form("From") Is Nothing Then

fromPhoneNumber = Request.Form(“From”)

End If

Next, we’ll get the Message Body from the page request
If Not Request.Form("Body") Is Nothing Then

messageBody = Request.Form("Body")

End If

And that’s it! From here, we can handle this data how we see fit.
Call LogDataToDatabase(fromPhoneNumber,messageBody)

End Sub

This is simplified for example purposes. You will want to setup error handling and logging in conjunction with sending the message, and will need to clearly define the business logic of when and who to send messages to.

Learn more about the service here : https://www.twilio.com/sms

Advertisements

Things I Wish I’d Known Preparing for Ground Truth – Part 2

Ok, in Part 1 of this post, we covered a good chunk of the lessons my team learned during our trip to China with the Executive MBA program at the University at Buffalo.

But, there’s more to earning solid feedback on your product from prospective customers than just delivering a sound demo. If you think there’s a different culture on the west coast of the US relative to the east coast, try meeting your customers in China! Before we grew comfortable listening, watching, and adapting in our new environment, my team risked coming back with nothing or missing the point, several times.

Get local through your errors. Before we departed, every book and coach told us not to drink the tap water. There’s not enough time to adjust on a short trip. Yet, one morning I slurped some while brushing my teeth, and didn’t realize it for several hours. When you adjust, you’ll probably do it by letting go. Just embrace it.

The Bottled Water Acid Test. Yup, we drank a lot of bottled water, and everywhere we went our hosts offered it to us. They watched as we drank it. Over time I thought this must be a stereotype of westerners. Or did it reveal how much I trusted the host? We were sensitive too, after hearing about refilled and resealed bottles. Rituals come in all forms.

Start early and make it easy. We scored seven meetings for two days. To do this, we started reaching out two months earlier. We avoided loading our hosts with any onerous work, especially reading long text blocks or keeping track. We reminded them of our meetings before we left the US. A couple of days before each meeting, we confirmed. One firm still moved a meeting from 10:30am to 8:00am, giving us just enough time to drop breakfast and run.

Forge a connection. To get those meetings, we tried a few strategies. Personal connections worked best, where someone had a cousin in-country and made introductions for us. Shared history scored too: did one of us go to the same school as a prospect? We got a 15% response rate from a targeted email blast to association members. To increase that rate, we could have adapted the request to be more relevant to each recipient. After meeting, most hosts shared a list of people we should speak to next, both inside their firm and at others. How kind!

Who are you talking to? On some of our tours, our hosts clearly spoke to the perceived leader of our crew first, and then to everyone else. It was striking. We soon tried it, using the business cards we received as strong hints about seniority. Would we have given them a disrespectful impression otherwise?

Help me save face! Once, we met with an operator and a manager and asked them to fill out a five minute survey for us. The manager sighed, rubbed his eyes, and said that he couldn’t complete it because he’d forgotten his reading glasses. Being super helpful, we offered to walk him through it. Much later, we realized our big mistake: perhaps his English wasn’t as good as his protégé’s, and he’d offered us a card to help him save face? We’d taken the card and burned it. Ach!

How close is too close? In a giant unfamiliar city, how much time should you place between meetings? In Beijing and Shanghai, one hour worked just fine for taxi travel. They were clean and quick (and almost always Volkswagen Foxes), and we asked our hotel concierge to write out directions in Chinese and English to give to our taxi driver. We brought the hotel card to get home again. We tried hard to keep our meetings to one hour, too.

Localization Details Matter. Localization is more than just translation. Our prospects remarked that they would consider us if we certified compliance with China’s legal framework. English is acceptable, but adding an interface in the legal form of Chinese would be better since it’s more widely understood than a particular dialect. Showing culturally appropriate use cases in our demo would have helped too. For example, Chinese occupants keep their rooms in the mid 70’s F. Who knew that detail beforehand? Our hosts might have wondered, “Why do these people always want me to freeze?”

Challenge or Business Opportunity? The list goes on. For example, there is wide variation between coastal and inland China, and rural and urban China, even more than in the US. At the time, there were no carriers able to deliver packages everywhere in China, and few fulfillment houses distributing for US firms. Each carrier had regional or urban-only coverage. Experience with computers and English varied inland, too.

Needless to say, the next time we collect on-the-ground feedback in China, we’ll be much better prepared. If you’re planning a project like this, consider doing it in stages, with time re-factor your approach each round. Everyone we met with was so helpful that I’d expect improvement to come quickly for you.

Things I Wish I’d Known Preparing for Ground Truth – Part 1

Since our founding in 1998, Algonquin Studios has acted as a trusted ally for several startups and has even launched a few businesses ourselves. By March, 2010, several Algonquin Studios team members had built a robust hardware prototype: a mesh network of sensors, controllers, and management software. It personalized the environment and access within commercial buildings and hotels. But the team had limited sales and installation experience.

Coincidentally, I had a trip to Beijing and Shanghai forming, as my team needed a capstone project in the University at Buffalo’s Executive MBA program. What a lucky match! Beijing and Shanghai were saddled with surplus real estate following the Olympics and investment booms and firms were hungry for smart competitive advantages. Why wouldn’t this solution work in China? My team set up in-person demonstrations and feedback sessions with hotel and property managers while we were in China, and brought back a trove of on-the-ground observations.

We were surprised at what we learned and the ways that were identified for doing things better the next time around. I’m sure you would be too:

Is that a prototype or a bomb? We brought several black plastic boxes as functional prototypes. Each was the size of a juice box and had LED lights and wires hanging out the side to batteries. Frankly, they looked like bombs to our American eyes. How would we get them through customs in China? It turns out they didn’t care.

Demos will break. How many ways can you give your demo? It had better be a bunch. At our first meeting we fried the Radio Shack step-down transformer we brought with us. But we had rehearsed in the hotel – how unfair! So what? We couldn’t find another transformer in any store. We would have been stuck giving vaporware demos, and our surveys would have just measured the dream in someone’s head. But, we found a way out – powering up with batteries or laptop USB ports. In fact, laptop wall power supplies adjusted to every location with just a reliable plug adapter and laptops could be recharged, unlike plain batteries.

Tricky Demos = No Demos. The developers warned us that the devices would jump to a different port every time we started a demo. My background is development, so I could resolve the problem without anyone noticing. But the rest of my team struggled when we split the team up to do two meetings at the same time. Remember, your goal on the ground is to get feedback and the talent you’ll have won’t necessarily be technical.

What does ‘done’ mean? Following that thought, we realized our demos could have been more polished. We built our demo around what the developers showed us. Why not build it around what evokes meaningful feedback? For that matter, make it look good so you’re not distracting prospects with a bomb, highlighting how far you are from done, and maybe getting them to feel like they should work with a cool outfit like yours.

How will you pay for that? Business credit was new in China in 2010; most paid by bank transfer or online services like AliPay and TenPay. Not one of our prospects chose credit cards as a possible payment method. One kind soul wrote, “There are no credit cards in China.” We could have figured that out from a few web searches, but we didn’t do the due diligence. So, did we miss a chance to get better feedback?

Integration and Management Services. Don’t forget that a hardware solution lives in an existing context. Every one of our prospects asked how we would work with their existing systems and offer administrative tools. If you can’t do this yourself, it’s smart to partner with a firm such as Algonquin Studios.

Sales Channels. Who will your prospects buy from? Our prospects suggested that we partner with a US firm already established in China, increasing trust, avoiding intellectual property theft, and offering integration options. Even a two-person local sales team with an engineer would be better than selling from outside China. You might need local help to get products out of customs delays in port.

Each building is an island. Treat each prospect as a unique case. We met with hotels and property managers, very concrete examples. We were surprised to find that each hotel provided its own utilities and services, including massive electric, water purifying, and emergency outfits. Less literally, don’t make assumptions about the rules. Listen first.

Even if you’ll open your business in your home market, or your foreign market is in the west, there’s more to ground research than just product demos. In fact, we wouldn’t have gotten any feedback without adapting on the fly. How thrilling!

Stayed tuned for Part 2 of this post, which will cover our take-aways on the more “personal” aspects of cross-cultural market research.

Related links that rang true to me:

Tips for On-the-Ground Market Research
Global Health at MIT

Ground Truth and the Importance of Market Research
Karyn Greenstreet

Ground Truth
NASA

You Should Be Using Two-Factor Authentication. Everywhere.

We’re not very good with passwords, although we think we are. According to a recent study by security company CSID, 89% of us think we practice safe password routines. Unfortunately, 1 in 5 of us have had an online account compromised and yet only about half of us change our passwords more frequently than once per year. The best passwords typically utilize a combination of letters, numbers, and punctuation, and the longer they are the better (at least 8 characters). Only 6% of users have passwords that meet these criteria. Even worse, 60% of us reuse the same password for multiple sites. This is a recipe for disaster.

Here’s a quick scenario: Tommy has a forum account on a fan-made music site. The music forum that he visits regularly doesn’t maintain their security patches regularly, and a random hacker manages to hack into the site and steal his password. A simple web search reveals that Tommy works for Company X. Company X uses the Outlook web app, and wouldn’t you know it, Tommy uses the same password everywhere. Through a little trial and error, the hacker discovers that tommy@companyx.com is his work email, and boom, the hacker now has access to Tommy’s work email.

So what is two-factor authentication, and how does it solve this problem? Well, two-factor authentication (2FA) is a multi-stage method of verifying that you are who you say you are. Typically it’s a combination of something you know (a password), and something you have access to (a phone). Most commonly, the second factor of authentication will be a code that you will be sent through a text message or an automated phone call, and it’s only valid for a short period of time. This code will be entered on a secondary screen before you can have access to your account.

Unfortunately a lot of people don’t know what 2FA is – roughly 75% of people surveyed didn’t have a clue. It has also garnered a reputation for being a hassle, which is simply not the case. Most two-factor implementations will allow you to “register” a device as a “trusted device” for a period of time (typically ranging from a day to a month). I know what you’re probably thinking – what if I lose my phone? Then what? Well, the answer to that is “it depends.” Every two-factor implementation has different ways to handle account recovery in the event of a lost device, but this shouldn’t deter you from using 2FA – the benefits outweigh the risks by far.

So where are some common places you should start using two-factor authentication to protect your online accounts? Here’s a list:

  1. Google: Sends a 6 digit text message when you attempt to login from a new device. They also provide a Google Authenticator app for Android, iOS, and BlackBerry that can be used to obtain the second factor authentication codes.
  2. Apple: Sends you a 4-digit code via text message or Find My iPhone notifications when you attempt to log in from a new machine.
  3. Facebook: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  4. Twitter: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  5. PayPal: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  6. Microsoft Accounts: Sends you a 7-digit code via text message or email when you attempt to log in from a new machine.
  7. Yahoo! Mail: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  8. LinkedIn: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  9. WordPress: Utilizes the Google 2FA app.

For a more complete list of companies and products that support two-factor authentication, please review Evan Hahn’s list. Ask your local security or IT professional if your organization could benefit from using 2FA for email or work accounts. There are also ways to implement two-factor authentication into your own custom applications and web sites.

Passwords are becoming less secure all the time, and hackers are getting better at cracking them (check out the strength of your password). Enabling two-factor authentication provides an extra layer of security at a negligible cost. Protect your financial accounts, identity, and your career by using it wherever you can.

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.

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?