How to Tell When You’ve Been Given a Good Project Estimate

By | Enterprise Mobility, Thought Leadership

Let’s say you are a member of your organization’s IT Department, and you have engaged a third party vendor to develop a customized software solution for your company. When they provide you with a cost estimate for the statement of work, you will have to determine whether the estimate at hand provides good value for your company and can be delivered by the proposed timeline.

Here are five suggestions for how to determine if your software vendor has made a good project estimate:

Don’t Cut Corners During the Design Phase

In the hurry to get a Development SOW signed, design is often taken as ‘easy’ or as a ‘given’; however, rough drawings or high-level descriptions of what software should do does not provide enough information to understand the true complexity of a project. Good design often takes months. Companies who have deep experience in software development will have an active design team that will work hand-in-hand with the project Architect AND end users to detail each and every flow, feature, and edge case for a project. If your software vendor provides you flow diagrams, high fidelity prototypes (such as Invision click-throughs), detailed written requirements, and have had at least two full design feedback sessions with your software end users, you are in a good place. Money spent on design will almost always save you time and expense on the overall project. Read More

NFC Android

Is An MDM Really Necessary?

By | Enterprise Mobility, Thought Leadership

When rugged devices first were deployed into the wild, the modern MDM solutions we know today did not exist. The pioneers of enterprise mobility had to create solutions for the problems they faced. Early in my career at Accenture we essentially built a platform on top of Windows CE that allowed applications to shared common components in order for us to rapidly build mobile applications. However, so many of the legacy devices that have served in warehouses, grocery stores, airports, etc., need to be replaced and so should the old way of managing rugged devices.

Read More

Balancing Simple and Useful

By | Enterprise Mobility, Thought Leadership

Lots of buttons means it’s awesome… right?

I had a recent Uber ride in a Ford Explorer and was incredibly overwhelmed by the quantity of buttons on the dashboard.  It occurred to me that there must have been dozens, if not hundreds, of people in the design and review cycles for this product before it went to market.  I wondered if at any point in time someone stopped the meeting to ask: “Is this the best design for our average user”

By contrast, the picture below is of the steering wheel of a Formula one car. The design is by no means simple.  But, every one of the buttons is designed for a specific use case that the driver needs to perform during the race.  Nothing in the car is there because a designer said to themselves “I guess they might need a button to do XYZ… lets throw it in so the marketing guys stop bugging us about innovative features.”

Upon further analysis of my preferences, I realized I have a bit of crush on things that are very useful but are also simple.  The trick is to figure out how to balance these two sides of the simple/useful equation… It’s harder than you think.

Read More

What Should be in Your Mobile Proof of Concept

By | Enterprise Mobility, Thought Leadership

With most companies focusing on mobile strategies and investing heavily in software, tools and devices, there is a natural need to kick the tires before pulling the trigger on their next mobile-related investment. A proof of concept (POC) is an excellent way to test the feasibility of an idea or demonstrate a theoretical concept in practice.

My career path to Chief Executive Officer at BlueFletch was built on years of mobile proof of concepts. Many of these POCs have been in large enterprises and governmental organizations with a key focus on replacing legacy devices. Usually these companies require devices that are ruggedized and can survive in the end-user’s workplace environment.

We are entering another era of ruggedized device replacement for enterprises. The current fleet of devices in service are well past their service lifetime and are running Microsoft Windows CE, with an operating system that is effectively 10+ years old. Others, are running terminal emulation applications that should have been replaced in the late 1990s.

Read More

The Future of Batteries in Mobile Devices

By | Enterprise Mobility, Thought Leadership

Editors note: This post was originally published in September 2015 and has been completely revamped and updated for accuracy and comprehensiveness.

Are you suffering from any of the following symptoms: panic setting in when your phone’s battery is dying, frustration from not being able to find an open outlet at the airport, or being tangled in a web of charging cables? You just might be one of the billions experiencing inadequate battery life in smartphones.

Lithium-ion has dominated consumer electronics as the rechargeable battery of choice for years. These batteries are chosen by device manufactures for their high energy capacity and high cycle life, meaning they can be charged and discharged many times without degrading. However, lithium-ion technology hasn’t changed much in 20 years despite the shrinking and thinning form factor of mobile devices and the increase in complexity of software.  There have been only marginal improvements to capacity, but manufacturers leverage it to power advanced chip and graphic specs instead of increasing device uptime.  

Simply put, if you want more battery life out of a lithium-ion battery, you are going to have to purchase a larger device to house a larger battery. As long as the current materials for Li-ion batteries are used, there will not be a substantial improvement to battery life. The ceiling for battery life is only so high due to size/efficiency constraints of lithium-ion.

Looking towards the future, I will highlight emerging battery and charging advancements that will revolutionize battery efficiency.

Battery Technology


Source: Oxis Energy

Sulfur has long been used as an electrolyte in batteries due to its natural abundance on earth, but sulfur is not a great conductor and deteriorates easily.  Researchers at both UT-Dallas and Penn State are now experimenting with adding molybdenum to the sulfur, which has shown to increase stability and conductivity to a point where it could be commercially viable.

These advanced compounds overcome the capacity ceiling of lithium-ion and are less expensive to make, weigh less, and are better for the environment.  Initial testing has demonstrated 3x to 5x improvement in capacity as compared to Li-ion, and therefore 3x to 5x battery life in your smartphone.  Coin batteries have been used for lab testing, however the compounds could be applied to smartphone batteries in the same manner.

Currently, issues with stability over many charge cycles need to be proven but the rising cost of materials to create traditional lithium-ion batteries and the high environmental impact will push for the advancement of Lithium-Sulfur (Li-S) sooner than later.


Source: Samsung

Researchers at Samsung’s Advanced Institute of Technology (SAIT) have created a battery made of graphene “balls”.  The synthesized graphene and silica, in the shape of spherical structures, are used as the anode and cathode in lithium-ion batteries.  Lab testing has shown these batteries can be fully charged in as little as 12 minutes (5x faster) without risk of overheating.

While recharging batteries quicker is desired by consumers, this material does not yet increase the capacity of the Li-Ion battery and therefore does not affect battery life.  Samsung has filed for a patent in both the US and Korea and we could see this rapid charging tech added to their consumer devices first.

Read More

Starting a Project the Right Way

By | Enterprise Mobility, Thought Leadership

Workshops are an easy way to get projects off to the right start, which is one of the many reasons why BlueFletch encourages these engagements.

If setup and run correctly, these sessions can reveal the client’s needs, business goals, and written assumptions, while also allowing your team to better determine the cost, effort, and risks of a project. Ultimately, the goal of a workshop is to define the project roadmap and help stakeholders move from uncertainty to certainty.

Sure, there are some scenarios where a workshop may not be necessary; for example, if you have worked with a client before, know their working style and have clear documentation of the project goals, a workshop session may not be the best use of everyone’s time. However, if you’re working with a prospective or new client, workshops should strongly be encouraged. If a workshop doesn’t take place, you run the risk of misconstruing project objectives, scope and deliverables, slowing down a project (you can cover in one workshop what you might cover in 5 shorter meetings), missing an opportunity to showcase your team’s expertise and thought leadership, and most importantly – getting into business with a client that doesn’t jibe with your company’s principles and culture.

If conducted properly, workshops can bring a high level of clarity into the conversation, enabling you to understand the project requirements, functional specifications, content modeling, solution architecture, and so on. But to run an effective workshop, a degree of preparation and strategy is required beforehand.

Here’s some key points to consider leading up, during, and after the workshop:

Read More

Determining the Appropriate Test Strategy for Your Project

By | Enterprise Mobility, Thought Leadership

Congratulations! After extensive meetings to finalize requirements and solidify designs and many intense hours of coding, what once existed as a potential solution to a client need is on its way to becoming a fully tangible mobile or web-based application. I know you are so relieved. Your completed application will soon be in the hands of your desired users. You are so excited to give them an awesome product! They are going to be so happy with it that they’ll tell everyone they know how much they appreciate your hard work!
Read More

Why We Do Requirements

By | Enterprise Mobility, Thought Leadership

It’s all in the details.  At BlueFletch, we don’t shy away from dedicating the time and resources needed to fully understand your solution and provide guidance in choosing the right technology.  From technical architecture to security specifics, we partner with you to ensure comprehensive requirements are captured for planning and traceability.

Gathering and reviewing requirements at the onset of a project is critical to identifying, understanding and solving the right problems and to support successful development and delivery.  We use a variety of approaches and tools: ride-alongs and shadows, interviews with stakeholders, white boarding, process mapping, etc.  The requirements process is the planning stage necessary in order to enter the design process with momentum and minimal back-and-forth.  The easier our team can reference and understand requirements, the higher our efficiency going forward.

First steps

Do you have a problem that you are ready to solve?  We will scope out the effort and provide project roadmaps and estimates.  Our requirements process begins as soon as your end goal, product or solution is communicated with us.  We research the line of business, competitors and mine similar projects we’ve worked on for insights and potential risks.

mobile app project roadmap


Our initial effort is to prepare a rough index of user stories and apply best practices and past learning to create initial artifacts on which to collaborate with stakeholders.  We then schedule requirements and design meetings, usually limited to five or fewer stakeholders and decision makers relevant to the session’s topic.  Limiting sessions to a manageable size reduces tangents and allows thorough understanding and documentation to build an exact solution.

During the sessions, there are often open questions and takeaways for the group.  Not everything has to be solved in one sitting.  There is great brainstorming that occurs when your idea is deeply analyzed and we are sure to capture all notes for future use.

After the meeting

The output of the requirements process is technical workflows highlighting integrations, user workflows, technical architecture diagrams and our master requirement tracking file.

Not only will these artifacts assist in your decision-making, but they will also be the reference for our project planning.  We create development and quality assurance tasks based each user story’s requirements.  Functional or non-functional, every requirement should be captured and tested.

Continuing into the project lifecycle, requirements will evolve. They are then updated and revised to match new discoveries and design decisions.

Mobile Strategy Workshops

If your organization is looking to accelerate their mobile projects, we provide a free mobile strategy workshop covering a variety of topics tailored to your specific interest areas. A mobile strategy workshop is an opportunity for your team to pick our brains about our experience developing mobile solutions. Past workshop topics include: development tooling, hardware interaction, UX design approach, deployment process, and domain specific mobile principles (retail, logistics, and warehouse). To learn more about our free mobile workshops, learn more here.

Managing Proof of Concepts

By | Enterprise Mobility, Thought Leadership

We can all agree with the saying “practice makes perfect,” whether it is learning your ABC’s at a very young age and turning your ‘jello-minto-p’ into ‘l – m – n – o – p’; or the young athlete practicing your free throws, backhands, bunts or putts for hours and hours in preparation to be the best in the heat of competition. Corrections and modifications bring us closer to achieving our goals and help us recognize failures. Similarly, a proof of concept (PoC) is a step in the process to achieving your business goal. Companies utilize this process for various reasons, such as gaining a competitive advantage or creating a better customer experience.

In my career I have found enterprise companies struggle in executing this step-by-step process. I have been tasked with managing and running PoCs for companies many times over and have gained key insights into how to achieve the stated goal.

What is a Proof of Concept

 Wikipedia defines Proof of Concept “PoC” as the realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be complete.

It is important not to blur the lines of PoC, demonstration (demo) and minimal viable product (MVP). A MVP is the minimal execution of a product that is released to customers. A demo or demonstration is just that, an example of a working process. No more, no less. A PoC is one step in the trial and error process that validates or invalidates a process for a given task.

A PoC troubled from the start

 This year one of my clients, a globally renowned brand, referred BlueFletch to an internal team to help them with a project. The project entailed helping them run a few PoCs. I was excited because the work was right in our wheelhouse. Below is brief dramatization of our one and only conversation.

  • CLIENT: Based on the requirements I sent over for the Green team, we are looking to obtain a better process capturing and reporting on important information. My goal is to define a process for running small, week long PoCs for internal teams for a strictly defined budget. Is this possible and how you would technically solve for this?
  • BlueFletch: I have reviewed the requirements as well. Has the Green team shared with you their top priority for this project? Have they defined any metrics that would help us prioritize the features defined in the requirements to obtain a better process?
  • CLIENT: BlueFletch, what is really important is understanding how I can define a repeatable process for running internal PoCs.
  • BlueFletch: Ok. So what does success mean to you?
  • CLIENT: Can we achieve my goal or not?
  • BlueFletch: I’m unclear of the goal. We can definitely work on a process for a week, but when you deliver the output of the PoC to the Green team how do you know if you were successful or not?
  • CLIENT: Because it will be delivered.
  • BlueFletch: What if we do not finish the process in a week?
  • CLIENT: Then we will give you more time. My goal is to deliver what we scoped in the requirements to the Green team.
  • BlueFletch: That is not a PoC. That is an MVP.
  • CLIENT: That is the process I am trying to execute here.
  • BlueFletch: (face palm)

The client wanted us to deliver an MVP for a PoC price and time frame. Even if the scope of the effort was large enough, the fact we could not agree on success from the start is a red flag that is commonly overlooked.

Read More