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.

Advertisements

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.

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.

Know Your Requirements!

Often times at Algonquin Studios, clients ask us to improve on their current software solution. The existing solution is either out of date or it simply isn’t giving the client what they need. For the user, changing systems can be a scary proposition. People grow comfortable with what they are accustomed to however, following a routine that you’ve done for years is the safe route. For this reason, it’s very important to sit back and think about what the system needs to accomplish. We want to make sure we maintain the output they are expecting from the software they use on a day to day basis, but keep an open mind on how to get there. In order to ensure this outcome, we spend a considerable amount of time conducting requirements analysis.

During the requirements analysis phase, one of the most important parts of a project, we determine what exactly the client needs are and how we will provide that solution. Time and again we run into the same obstacle of getting the client to see the difference between “what your users have today” and “what do you need the software to accomplish.” Clients often want everything they have today, in addition to the improvements we will provide with our software. Unfortunately, this could cause unnecessary features to be included in the software and add additional costs into the project going forward (training, support, system complexity … etc.). Costs that could be used elsewhere, either for the company or to build out additional features that are needed in the new system.

So, when coming into these requirements meetings it’s best to come prepared. To be better prepared it’s most important to know what is needed, as opposed to going screen by screen showing us everything they have today. There are many other ways to be prepared for these meetings, here are a couple:

Question your users

As a client, when was the last time you asked your user base about the program they use on a day to day basis? Requirements and business needs are always changing over time. Depending on the size of the user base, and the software being used, these questions could vary (and there are many). In the end, the client should find a way to determine:

  1. Which features are being used the most?
  2. Which features are rarely (if at all) used and aren’t needed?
  3. Is there anything you need the system to do that it doesn’t do today?
  4. Does the system provide repeatable work that the software doesn’t handle, costing people time every day?
  5. Are there current features that need to be revised to accommodate current needs?

There are many ways to gather this data.

Is this software internal, used by only a handful of people in your office? Have a meeting to review the software and gather the information firsthand from the users. Come prepared to ask about features that work and those that don’t. Are there any that have lost value over the years?

Do you have thousands of users using the software across the United States? Setup online user groups and invite people to provide valuable feedback on the software. Depending on the capabilities of your software, you can limit the groups to certain sections of the software and provide questionnaires about those sections. This should help you gather all the necessary information to bring to your developers, so we can make sure we build you an efficient, quality application that suits all your needs.

Clearly Define the Inputs/Outputs

Frequently, a screen can be so overloaded that one loses focus on what exactly is needed. Determine all the inputs of the screen and make sure they are all required and are what you need. Next, identify inputs that are unnecessary or misused. Keep in mind that just because they exist today doesn’t mean they’re needed going forward. Additional inputs only cause more complexity.

As important as it is to define the inputs, it’s equally important to define the outputs. Outputs that are currently delivered may no longer be needed or efficient or may simply be delivered differently in the new software; Once again, this is often difficult for a client to understand. Asking a lot of questions in the requirements meetings about those features can help ease the process because in the end, the more inputs/outputs you have the more complex your system will be. Our team of consultants are really good at letting clients know if the value they’ll receive from a feature is worth the effort and, generally, we can determine this during the requirements meeting.

In the end, if the client does their part in determining what’s exactly needed out of a system in order to eliminate all the old, antiquated screens and logic, the better the software will be. This will ultimately save the client in the long run.

K.I.S.S.

Nope, I’m not talking about extravagant costumes, black and white face paint, and fire breathing.

I’m here to discuss the old adage “Keep it simple, stupid” and how it applies to software development.

As a Project Manager, I spend a lot of time meeting with clients to review requirements for their software and work with them to turn those requirements into a full system. As I work with my clients to navigate the treacherous waters of system design, we inevitably end up with a “feature” that we all agree is on the borderline of “Necessary” and “Nice to have.” This is especially hard to determine in a business system that users will be working with every day.

This is when things get interesting! Let’s take a look at what questions to ask yourself:

Why do you want this feature?

You can tell a lot about how important this feature really is by the initial reaction of a client when you ask this question. If it takes a few minutes of fumbling to eek out a satisfactory answer, you can most likely scrap the feature.

Is it worth it?

To answer this one, we’ll ask a few follow up questions, too:

  • How often will this feature be used?
  • Is there a manual workaround that can be used instead of this feature?
  • Who will use this feature (and how many of these users are there)?
  • How much work will be created for a user is this feature is left off?

Now do a little quick math and, magically, we can determine if it’s financially worth adding this feature. Here is an example:

Add this monthly report that aggregates data for X, Y and Z. 
  • Feature will be used monthly
  • User can perform this process manually
  • 1 administrative user will use the report
  • If this feature isn’t implemented, the administrative user will need to run 3 reports and aggregate the data themselves. This process will take approx. 20 minutes.

Answer: If building the report adds 8 hours to the system build, it will pay for itself in 2 years.

Does this feature add complexity to other areas of the system?

I’ll let you in on a little secret, the answer to this question is always YES.

No mater how much you want this fancy new feature, it will make your system more complex. We often try to convince ourselves that a feature is so simple that it won’t add complexity, but there are a couple of points that always hold true:

  • This feature will need to be tested after every update.
  • The users of this feature will need training.
  • This feature will need to be documented in the help system (and maintained).
  • This feature will need to be discussed when future changes to the system are designed/implemented.

So, let’s return to our seemingly simple example report and apply these issues to the “complexity” question:

  • Will this report need to be tested? Yes
  • Will the users need training? Yes
  • Will we need to add help documentation? Yes
  • Will this report need to be updated if we make changes to report X, Y or Z? Yes

There’s no doubt about it–every time you want to add a feature, you’re choosing to make the system more complex.

Before you commit to a feature, ask yourself if it’s a system requirement and make sure you really understand, and accept, the increase in time, complexity, and cost that including the feature will entail. If the answer is “yes,” then let’s build it. But if there’s any doubt, remember, it’s never a bad idea to K.I.S.S.

App Store Meta Tags

Screen shot of Dominos home page on Nexus 7.
Why yes, Dominos, I’d love to tap again to get your real home page to order a pizza when I could have done it right here, below your over-sized app pitch that could be done in a tiny ribbon.

This is an adapted and updated version of a blog post on my site from last week. This post includes a real-world example of the feature.

This may be old news to some of you, but I haven’t found a place that collects this in one spot.

One of the most offensive experiences I have when surfing a site on my mobile devices is being forced to click through an advertisement for the site’s app in the iTunes store (even moreso when I am surfing on a non-iOS device). There is a fair number of sites I have tapped away from because of this (I also don’t expect to be served the page I came to see, but instead shunted to the mobile home page).

If yours is one of those sites, whether promoting your entire user experience or just a product, there is a less offensive way to present your pitch to users on iOS and Windows Phone.

Platforms

iOS 6

Safari on iOS 6 and later devices can promote your app with a standardized banner. Essentially you stuff a custom meta tag into your page that references your App Store ID. If the user already has the app installed, then the ad becomes a launcher instead.

The code is pretty simple:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

  • app-id is required and references your app’s identifier.
  • affiliate-data is optional and uses your iTunes affiliate string.
  • app-argument is also optional and can allow users who have your app installed to jump to a specific place in your app.

More details at Apple’s developer site: Promoting Apps with Smart App Banners

Windows 8

Microsoft offers a similar feature for users of Windows 8 in non-desktop mode who are also using Internet Explorer. I have not tried it, so I cannot explain how this works as the user changes modes nor how it works with the “charms” feature of Windows 8.

This code is relatively simple as well, though it requires two meta tags and supports up to five:

<meta name="msApplication-ID" content="microsoft.build.App"/>
<meta name="msApplication-PackageFamilyName" content="microsoft.build_8wekyb3d8bbwe"/>

  • msApplication-ID is required and references your app’s identifier.
  • msApplication-PackageFamilyName is required and contains the package family name created by Visual Studio.
  • msApplication-Arguments is optional and lets you pass arguments to your app.
  • msApplication-MinVersion is optional and can direct users with an old version to the Windows Store.
  • msApplication-OptOut

More details at Microsoft Developer Network: Connect your website to your Windows Store app (Windows)

Google Play, BlackBerry App World, Etc.

In addition to Google Play, BlackBerry App World, I looked for similar features for the Firefox OS and Ubuntu Mobile stores. I know there are other mobile platforms out there for which I did not look.

If you know of other app stores that offer similar features, please let me know so I can update this post.

Real-World Example

One of our spin-off companies, SWRemote, has an app available for iPads. There is value in promoting the app to visitors of the site but not in blocking their access to the site content with a splash page or an extra click, especially if they are not on iPads. The SWRemote web site is powered by QuantumCMS (yes, I am promoting our web content management system), which makes it about 30 seconds of effort to add the necessary meta tag to the site.

Screen shot of the QuantumCMS custom meta tag screen.
Screen shot of the QuantumCMS custom meta tag screen.

If you are already a client of ours on QuantumCMS, all you have to do is choose Site Configuration from the Settings menu and pop into the Marketing tab. This is the screen that allows you to add custom meta tags. Press the Advanced button and you are off to the races. In the Name field, for this example, I just entered “apple-itunes-app” and in the Content field I provided the custom ID for the app appended to “app-id=.” As soon as I hit Save the web site was showing the app bar to visitors:

Site on the iPad3 without the app installed. Site on the iPad3 with the app installed.
Screen shots of the SWRemote site on an iPad3 both with the app installed and without it installed, showing how the bar changes its message.

Oddly, even though the app runs on the iPad Mini, which is running iOS6, the app bar never appeared on the site when viewed on the iPad Mini. On an iPhone 5, the app bar started to appear and then disappeared — probably as the device recognized that there is no iPhone version of the app.

If/when there is an app available for Windows Phone, the process to add this feature will be the same, allowing the site to promote both apps dependent on the audience. QuantumCMS helps make the process easier, with no need to code any changes to your site templates.

Related

There are other places where custom meta tags are used to display targeted content. One example is used for Twitter Cards and another example is used with Google News. While you can build support for them, neither Twitter nor Google is going to use them unless you have been vetted in advance.

Code Reuse: a Blessing or a Burden?

In the world of development, coders are constantly faced with the problem of creating efficient code under a very tight deadline. The idea of Code Reuse, simply the use of code created by another developer, has been a staple concept in the world of programming since the start of development. Whether it is an open-source library or code written by a stranger on a frequently-visited forum, every developer has utilized code reuse at one point. Code reuse definitely has its place in development, but should we rely so heavily on this model?

The first thing you need to think about before using someone else’s code is, “Do I have the right to use this code?” It’s becoming commonplace to see a lawsuit based on one company stealing code or concepts from another. But, beyond the legal reasons against using other’s proprietary code, there are also the ethical obligations that everyone should consider for leaving this code alone. No developer wants their own work to be stolen, so it’s also their responsibility to not steal code that doesn’t belong to them.

Not all code is proprietary though. There are entire communities that revolve around open-source libraries, made to benefit everyone. Here at Algonquin Studios, we have a monthly meeting during which all of the developers get together and talk about the technology they either are working on or want to work on. Our last meeting was based around third-party solutions and not “reinventing the wheel.” If there are solutions to your problem already in existence, why should you waste the time of your employers and clients?

I agree with the idea that if a proper solution exists, there is no reason to recode the solution. The fine line lies with the word “proper”  though. Too many times, I’ve seen a complex solution to a problem be reused in many places it shouldn’t. Usually the solution gets a “band aid” so that it works within the scope of the new problem but this just evolves as more closely-related problems emerge and eventually the coder ends up with inefficient code that barely solves the problem. The world of development has  begun to rely on third-party libraries and frameworks and other people’s code so much that they sometimes have no original code in their project and there needs to be a happy medium between quality and speed of development. Sometimes it’s worth it to rewrite an entire procedure that isn’t quite getting the job done. Sometimes you have a completely unique problem that someone else just hasn’t encountered before.

I still go back the “don’t reinvent the wheel” idea. If you can use other code that’s available and satisfies the problem in an efficient manner, then it’s a good solution. We all need to realize, though, that wheels come in different sizes and shapes. You wouldn’t want to put a hamster wheel on your car, nor would you want tractor wheel in your amusement park instead of a Ferris wheel. In the end, code reuse is a blessing to developers. Being able to create rich software at a fraction of the time spent is a very powerful tool. The developer just needs to learn when it is appropriate to reuse code, and when they should develop a solution specific to their problem.

NoSQL Databases

In a software developer’s world, the word “database” usually means “SQL.” SQL stands for Structured Query Language and, for years, this language has been the de facto language of relational databases. This includes Microsoft SQL Server, PostgreSQL, MySQL, and Oracle.

These database have served us well for literally decades, but there’s something new on the horizon. These days, all the cool kids are using NoSQL databases. NoSQL databases are document based, which means that they don’t have a schema or rely on the time-tested Structured Query Language. This is somewhat difficult for many veteran programmers to process. A big question that’s immediately raised is, “How would one communicate with a database that doesn’t use SQL?”  The answer can vary between the many different databases out there, but we’ll use one in particular as an example: Mongo DB.

Mongo DB uses the popular Object Oriented language JavaScript to interact between the software and the developers. This gives the developer the powerful advantage of using JSON to pass data between the Mongo DB collections and the application interacting with the database.

Developers that have a basic grasp of Object Oriented programming should be able to pick up NoSQL databases very quickly. For example, the SQL query to create a database which looks like this: “CREATE TABLE User (Ident INT IDENTITY, FirstName VARCHAR(50), LastName VARCHAR(50))” can be written simply as this: “db.CreateCollection(‘User’).” Since there’s no schema to worry about, any data points can be added at-will within the Mongo DB collection.  For more SQL to Mongo DB translations check out this mapping chart on the MongoDB site.

NoSQL databases are already in use in many popular applications that are familiar to almost everyone. Facebook uses a NoSQL database called Cassandra and FourSquare uses the aforementioned MongoDB. The list is growing with the popularity of these databases increasing on a daily basis. And NoSQL databases like MongoDB are available for every major system, so it’s possible to put these into production today.