Archive | information technology RSS feed for this section

When to Engage an Outside Design Team

8 Jun

Design provides value to a business at any stage, but there are specific points in your company or project where engaging with a design firm provides the maximum amount of value to your organization.

Here are some of the best times to bring in outside support from a design team.

When you need help articulating an idea

You might have specific ideas around the next iteration of your product and are wondering what to do next. Maybe you have some sketches on a napkin that you want to socialize internally or with strategic partners.

At this point, design can help with customer research and validation to ensure your idea is strong and defendable. From there, an infographic, strategy deck, prototype or storyboard can help you start gathering real feedback from your customers or stakeholders.

When you don’t have in-house design leadership

Depending on your company, you might not have sufficient design talent in-house. Maybe you only have access to a small team of designers, but what your project really needs is a seasoned design team to lead the initiative or share the methods and process to inform the organization of a user-centered approach.

Senior designers are capable of seeing the larger project vision. They’re communication double-edged swords: they can keep junior designers on task, while also communicating high-level strategy to stakeholders.

Experienced design teams bring to the table a set of standards and best practices that your team can rely on and reference. The devil is often in the details, which is where a seasoned design team with years “under their belt” can set you up for success.

When there is uncertainty on direction

Have you ever realized that you spend more time talking about what you’re doing than actually doing what you’re doing? If you answered yes, you’re not alone.

This is often a signal that your team is unclear on what you’re building and where you’re headed. Working with a design team at this point helps align the team around a vision — a vision that’s created through the lens of your customers. At this point, design can also help to create a shareable document or prototype to communicate your product’s direction.

There’s too much work and not enough talent

So much to do, so little time — and so few resources. Maybe you just raised money, have a new opportunity or a shorter timeline. Either way, you could use some support to come alongside your team.

Bringing in an external design team, especially one that is accustomed to collaboration, can help give you the extra hands you need while also bringing an often-needed set of fresh eyes.

You’re looking for new ways to serve your customer

There are a million ways to provide value to your customers, but you’re looking to find the one that works best for you. Because you live and breathe today’s version of your business, customers and product, you could potentially use some help planning for the future.

An outside design team is a great way to generate insights, new opportunities and product ideas. They will start by using you and your customers to learn how things are today and then help imagine how they add value tomorrow.

You’re looking for ways to be better

Products and brands can become stale after a while and you may be looking for a refresh. You also might realize that your customers have changed over time and your messaging no longer speaks to them.

Utilizing a design team can help by seeing how you resonate with customers. They can test and gather insights to help with your next iteration.

These circumstances encompass some of the hardest problems organizations face and engaging with an outside design team is an efficient and valuable way to solve them. This inherently collaborative process aligns the key players in your organization to strategically meet your customers’ needs and provide value.

 

Andy Van Solkema, OST Chief Designer

Andy Van Solkema, OST Chief Designer

Functional design systems, and visual storytelling have long been a passion for Andy Van Solkema. From boyhood days of designing a neighborhood baseball league complete with team logos to designing for local, regional, and national companies, his passion has grown and evolved to leading a 12 person studio that is using design for unique outcomes that span stories, systems, processes and experiences.

Andy is a graduate of Grand Valley State University with BFA in Graphic Design and a Master’s of Design from Kendall College of Art and Design. Following graduation, Andy worked as a design consultant in the printing industry, graphic designer and art director in brand communications, and as an interaction design director. He enjoyed the variety of experiences, but ultimately something was missing.

In 2004, he started his own design studio, Visualhero Design. Initially working as a one-person shop in a home office, Andy grew the business in a slow, steady and smart way through the down economy. To differentiate themselves and to offer the most to their clients, in 2006 Andy and his team formally adopted user-center design principles with a research and systems approach to creative problem solving. In 2016, Visualhero was acquired by OST where Andy now serves as Chief Designer.  His team focuses on form, function, and meaning. The scope of work has grown to include graphic recording, data visualization, brand identity, interface design, information architecture, user experience and customer experience. They design brand communication, applications, websites, and business systems and processes that aren’t just easy on the eyes.  More importantly, they are designed for the user today and tomorrow.

Van Solkema has combined a systems and process mind with craft of design and creativity. He spends his time as an advocate for design, creative lead for the team, and managing design vision for OST / Visualhero Design. Although most days are spent directing design, running the business or meeting with clients, he enjoys using his experience helping GVSU Design Thinking Initiative and various nonprofit organizations. He also enjoys leading design workshops at his alma mater and other design education opportunities. 

Andy has been published in design books and publications and received accolades and awards for branding and design. Design has changed and although he is firmly rooted in West Michigan, the clientele has grown to include Amazon, Nest, Apple, Chamberlain, Capitol Studios, GM and a host of local, regional and national corporate clients, a handful of local and Bay Area startups. Well beyond what Andy could have ever imagined back in 2004. 

Let’s Talk Ketchup

1 Jun

ketchup

I was in a conversation yesterday about a forecasting tool we use to manage our sales pipeline in Application Development. I’m frustrated about some of the tool’s limitations, and I was ranting to one of my peers, Rob, that I wanted to throw it out and build something new.

Rob tilted his head to me and gave me a narrow gaze. “Or…”, he offered. “You could just find a way to make it better.”

And that’s something, I am embarrassed to say, that hadn’t occurred to me. As a self-proclaimed smart guy who sometimes wears the mantle of leader, I all too often feel like it’s my job to generate new ideas, to create new solutions, to invent my way out of any issue, dilemma or challenge. Because what’s more American than creating things, am I right?

Which makes me think about ketchup.

What’s more American than ketchup? We put it on our burgers, we put it on our fries, on our eggs, our hash browns, and in our macaroni and cheese. We serve it with our breakfast, our lunch, and our dinner. No less than 45 American companies manufacture and distribute their own variations of ketchup to every corner of the globe. The red on the American flag might as well be painted with it – it’s that American. When was the last time you went to a casual restaurant or “American Bistro” and they didn’t have a bottle at the ready, or pre-set at your table?

It’s as American as apple pie. More! As American as freedom! Ketchup is the liquid equivalent of a bald eagle clutching a McDonalds bag as he soars over the Rocky Mountains and into the setting sun. It’s that American! But where did this stuff come from, this American red gold?

Does it matter?

Let’s dig a bit and see. Ketchup came to the Western world in the late 17th century, given to European traders in their travels to the Far East. There are stories dating back to 1690 which describe a vinegary, pickled condiment found in the Fujian region of coastal China reportedly called “ke-chaip”, and similar stories from 1710 and ’11 describing an Indonesian “brined” sauce referred to sometimes as “kecap” and sometimes as “ketjap”.

Nobody knows what it was about this exotic condiment that westerners found so intoxicating, but we sure did love it. We were making catchup in Great Britain as early as 1727 – nearly 50 years before the American Revolution! The condiment was so important and pervasive that it had already found its way into a “new world” cookbook as early as 1801. In America, catsup (apparently it was Americanization that changed catchup to catsup) was made regionally and sold by farmers across much of the 1800’s.

In 1876, the H.J. Heinz company started mass-producing their own unique blend of catsup, and – in the hopes that it would make their product stand out from the farmer’s alternatives – they decided to call their sauce ketchup. Over the next 10 years, every other manufacturer followed Heinz’ lead, and as the manufactured food industry exploded in the new world so did ketchup.

Fast forward a hundred and twenty-five years, your local grocer probably stocks between ten and twenty brands of ketchup (some even spelling it catsup again) – all manufactured in the U.S. and distributed to every country in the world. There are 196 nations on the face of our planet, and the one thing they have in common – all hyperbole aside – is the presence of ketchup.

Weird, right?

Americans didn’t discover or invent ketchup. We weren’t the first to create it, the first to document it, the first to fine-tune it, the first to trade it, or the first to sell it. We just took something good and made it better. We looked at what we had, and – through trial and error, through experimentation and discovery – we turned it into something better.

Which brings me back to my conversation with Rob.

We’re often in the situation that we need to determine whether to make something or to take something that already exists and make it better. In Application Development, we’re probably in this situation more than most; but I think everyone can relate: Fix the deck or build a new one? Steam-clean the couch or buy a new one? Sand and re-stain the table or buy a new one? When we’re in those situations, it almost always seems like the “best” choice is to make something new instead of taking something that already exists and making it better.

The next time you’re in that situation – and the next time I’m in that situation – consider this:

EASIER DOES NOT EQUAL BETTER

Just because it’s easier doesn’t mean it’s better. Just because you want to doesn’t mean you should. Just because you thought of it, that doesn’t make it the right choice. Maybe take a moment, the next time you find yourself facing a make it better moment, to dip your decisions in ketchup, that uniquely American condiment.

Americans didn’t make ketchup, We just made it better.

 

Andrew J. Powell Principal- Application Development

Andrew J. Powell
Principal- Application Development

Andrew Powell serves the Application Development practice at OST , providing guidance, strategic support, and candy to more than fifty developers and consultants. Andrew has been a technology consultant for more than twenty years. In addition to consulting, Andrew is a frequent public speaker in technology circles, and loves to talk about the coming Robot Apocalypse and how application developers are positioned to defend the world against our future robot overlords. When not cowering in fear, Andrew makes his home in Grand Rapids, Michigan.

 

ERP systems or your kid’s bedroom…nothing improves without a little extra work

11 May

messy room

(In the voice of the late Andy Rooney) “Did you ever wonder why clothes never pick themselves up off the floor?”

I have a degree in mechanical engineering, and though I’ve spent the better part of the last two decades working with ERP software, it seems I’m an engineering nerd first and software geek second. Sometimes that engineering nerd leaks through when working with ERP software.

Many times over the last 20 years or so, I’ve encountered the Second Law of Thermodynamics in action. What does that have to do with ERP systems? It’s actually a great analogy to what I observe time and time again.

The second law deals with Entropy. Entropy can be defined as a property of a closed system and is a measurement of the amount of disorder in the system. Organized = low entropy. Chaos = high entropy. My wife’s closet = low entropy. My basement shop = high entropy. The second law says, left to itself, the entropy in a system will either stay the same or it will increase (become more disorganized). It never decreases by itself. In order to decrease entropy, you have to add work.

You see this all the time. A common example is adding some sugar to a beverage. It may sink to the bottom at first, but it will eventually dissolve, becoming diffused through the beverage. It has gone from an ordered state of a solid to a less ordered state of a solution. The sugar will not, by itself, “un-dissolve” to the bottom of the glass again. If you want to get the sugar out, you will have to do work.

You see it every day next to the kitchen sink as dirty dishes, or the clothes on the floor in the kid’s bedroom. Or the autumn leaves in the yard, or the general state of the garage. Entropy is all around us, and it’s always increasing unless we work to reverse it.

I see this also applying to ERP software. ERP software is all about making order from chaos. It allows organizations to know the financial position of the company, or the state of inventory in the warehouse, or the planning of materials in manufacturing. Companies see features like locations in warehouses, or item lot control, or multi-dimensional accounting; and they think they can get better control over their business processes. And they can. But they forget that they are trying to reverse entropy and that requires work.

ERP systems promise to make it easy to add control. Just create locations in the warehouse so everything has a place. Or add commodity codes to the part numbers so you can report on them. Or have a gazillion ledger accounts to track the most minute cost. If that is what your business needs, great. But regardless of what the ERP system promises, remember that essentially what you are asking for is a reversal of entropy. If the organization is not willing to put in the work to maintain the commodity codes, or mapping costs to ledger accounts, or making sure everything is in its place in the warehouse; you can actually end up with more chaos.

When implementing ERP systems, or any system for that matter, organizations should think about the effort required to maintain that system and if they are willing to expend the effort and define who is responsible for the effort. I have seen many instances where an organization decided to put a control in place, but never assigned responsibility or allocated the resource to maintain it, and as a result ended up with more entropy than when they started.

Entropy… it’s so prevalent we don’t even notice it unless we think about it. But when it comes to ERP systems, we need to be mindful of it when making configuration decisions.

 

Dave Trayers- ERP Business Development Manager

Dave Trayers- ERP Business Development Manager

Based in the OST Minneapolis office,  Dave Trayers is the Business Development Manager of the OST ERP team with over 17 years of Baan/ERPLN experience.  A native of New England, Dave holds a degree in Mechanical Engineering; and before getting into IT worked in diverse fields ranging from nuclear attack submarines, aerospace materials, snack food production and automotive tools.  He’s held the position of manufacturing engineer, production supervisor, engineering manager and operations manager.

Immediately prior to joining OST, Dave was the IT Director for Nilfisk, a manufacturer of commercial cleaning equipment in Plymouth, MN and throughout North America.  He helped implement Baan IV in the late 90’s and two major upgrades to ERPLN (FP3 and FP7) since.  Nilfisk made several acquisitions over the years, so Dave has lots of experience in bringing new facilities into ERPLN.

Dave lives in Minnesota with his wife Liz.  He has two grown daughters, one in college and the other lives in Washington, DC.  In his spare time, Dave is a part-time professional photographer, and enjoys golfing, cycling, sailing and target shooting.  He is also chair of the board of Saint Paul Ballet, which means he has very little time for golfing, cycling, sailing and target shooting.

How to embrace the principles of Agile software development

13 Apr

Those who know me well know that I am obsessed with Alexander Hamilton. He’s the founding father you didn’t learn about in US History, mostly because he never became President. You probably know he was killed in a duel with Aaron Burr, you might even recognize him as the dude currently gracing your ten-dollar bill, but you probably don’t know that he was an orphan, an immigrant, and the guy who single-handedly created America’s financial system. (You should also thank him for the Constitution’s ratification – he wrote 51 of the 85 essays that make up the Federalist Papers.)

My obsession with Alexander Hamilton has taught me a number of things – about myself, about my work, and about how to simultaneously serve with humility and fight for what you believe in. More surprising, though, he’s also taught me something about embracing the principles of Agile software development.

 

“A well adjusted person is one who makes the same mistake twice without getting nervous.”

 

Think about that for a minute. It seems to run contrary to everything you were taught in school, doesn’t it? Making a mistake is bad enough, but making the same mistake twice, that’s unforgivable! We think of a mistake as the opposite of a success. We’re wrong.

Our software development delivery process at OST is based on the Agile Manifesto (www.agilemanifesto.org). The Agile Manifesto, and Agile software development in general exposes to us a core concept that iteration is a key to success. Responding to change wins out over following a plan every time.

In software development, this makes sense. Try something. If it doesn’t work, try something else. Do something. If it doesn’t match the user’s expectations, learn from it and do something else. Build something. If it doesn’t satisfy all of your needs, build more. This is how we do what we do. We start somewhere, and then we iterate. We test out ideas and approaches. We validate concepts and database constructs. We build, tear down, and build again. We iterate, iterate, iterate; each generation an improvement on the last.

It’s great! It’s a process that makes great solutions, and a framework that sets projects up to continually improve. At its core, continuous improvement requires that you have room to improve; embraces the notion that there is always opportunity to improve.

In life, though, that’s a hard concept to wrap our heads around. We don’t provide ourselves with a lot of grace to make mistakes. We tend not to look fondly on things that need improvement. And our lexicon is full of really awful words that we toss around at ourselves (and others) when things don’t go as well as we hoped. You failed. You blew it. You screwed up. You made a mess of things. You got it all wrong. You lost sight of the big picture. They’re terrible, soul-crushing words. Defeat. Collapse. Crash. Bomb. Die. They’re all words and phrases we employ to remind ourselves just how awful it is to fail.

Enough already!

Here’s what Alexander Hamilton taught me. It’s not awful to make a mistake. It’s essential. Let me say that again – it’s that important.

Failure is required for success.

It’s a foundational principle in practical Agile software development, and a foundational principle in life.

Fail. Make mistakes.

Then learn from them.

 

Andrew J. Powell Principal- Application Development

Andrew Powell serves the Application Development practice at OST , providing guidance, strategic support, and candy to more than fifty developers and consultants. Andrew has been a technology consultant for more than twenty years. In addition to consulting, Andrew is a frequent public speaker in technology circles, and loves to talk about the coming Robot Apocalypse and how application developers are positioned to defend the world against our future robot overlords. When not cowering in fear, Andrew makes his home in Grand Rapids, Michigan.