Business: Consulting

If you use—or want to start using—an agile-development process, you probably already know its benefits, but you might not be as aware of one of its main drawbacks. Even though 46% of US organizations and 85% internationally report that they’ve used an agile approach within the past year, communicating your agile process to clients remains a challenge.

Specifically, the problem is bridging the gap between clients’ expectations of the process and the way agile really works. But overcoming this difficulty is well worth the effort if you wind up with a first-rate product and a fully satisfied client.

Of course, some clients are already quite familiar with how agile works. However, for those who aren’t—and whose previous experience was with waterfall product-development approaches—explaining the process and merits of agile can be tough. Sure, your clients might know some agile buzzwords, be familiar with some of the tools, or know the importance of meetings to the agile process. However, it’s unlikely that they understand how agile actually works in practice. Read More

Now that you’ve convinced a client they want to work with you, it’s up to you to define the terms of your working agreement. Your goal in the contract negotiation process is not to determine the best price, but to most accurately define the scope of your project. This is possibly the most critical factor in the success of your project, and it’s something most consultants completely fail to follow through on.

A Statement of Work (SOW) formally defines the scope of the activities and deliverables for a project. BusinessDictionary.com defines scope as the “chronological division of work to be performed under a contract or subcontract in the completion of a project.”

Some clients have a very specific chunk of work in mind, while others just know they need help. In either scenario, use your expertise to determine the appropriate amount of work to tackle, according to several key variables: needs, resources, location, schedule, and budget. Read More

I began my career over twelve years ago in marketing, defining the user experiences for healthcare Web sites at an interactive agency. At first, I loved the dynamic environment and start-up feel of an agency. It felt great that a large audience would interact with the sites that I helped design. Over time, however, I realized that I wasn’t doing good UX design. Rather, I was doing whatever the agency Account Manager or client Brand Manager wanted, which didn’t always jibe with what customers needed. The Account Manager or Brand Manager wanted site registrations and glossy, auto-play video tours, while customers needed educational content and information about financial assistance. I had lost the integrity that had driven me to choose user experience as a career in the first place. I wanted to design great user experiences for people based on their behaviors, needs, and preferences—not the whims of the agency or client. So, after five years, I decided to leave the agency to work on internal applications at an IT (Information Technology) consulting firm. Read More