Friday, September 30, 2011

Project Management for Real Life

Most people would agree with the notion that project management is a blend of art and science, often governed by the iron fist of a project management methodology. Using a Fancy, Formalized Methodology (an FFM™) can provide a mature and organized framework for project execution. There are several reasons why it can be tempting to use an FFM™ to drive your project.

  • Comfort: Simply put, a highly formalized approach can bring rigor and proven practices to an execution effort, and knowing it has a "big name" can provide the same smug comfort as knowing you bought a Cadillac. But
    beware: If your project or business demands agility, an FFM™ can be a slower and less responsive execution model.
  • Process: An FFM™ can provide delightful checklists and procedures, giving you a recipe of rote steps that represent accumulated best practices. But beware: Even if you follow these steps utterly perfectly, it doesn't necessarily mean the project will be a business success.
  • Reporting: An
    FFM™ has extremely mature reporting mechanisms, which can ensure thorough communication across complex groups of stakeholders. But beware: This reporting will cost your project time, which is a luxury you may not have. It's also expensive.

Successful projects depend on good ideas, good connection with user need, passion, and dynamism – not to mention good people. Remember that while an FFM™ can provide useful tools and techniques, how you apply them
is still
up to you. Look for a partner that can provide project management rigor, without squelching the creativity and agility that innovation demands.

Set Your Developers Free

Even products have awkward adolescent phases.

Picture yourself in this scenario: You are the VP of engineering at a hot startup. Your development team has spent the last year building a product. They have poured blood, sweat, tears, and more than a few beers into building something to ship out the door and sell to a million customers. And the product is out the door.

But you're not to the million customer mark yet. So far, you've only sold to 13. Those 13 customers are calling your developers for support… a lot. And you're wishing your developers could be spending their time building snazzy new features for v2 instead of taking support calls.

But what can you do? You don't have enough customers or money to warrant hiring a support engineer in house - and the idea of outsourcing the support work for a product that only has 13 customers isn't rational. Right? Wrong. The support of your product is just as critical as the way it was built. Support is the easiest way to interact with your customers, and get valuable feedback that can enable the iterative improvement of your product. And there are options for a successful support model, even when cost is an issue, your product hasn't fully matured, and your customer base is small.

  • Take it offshore. Establishing a small team of specialized support resources offshore can significantly lower your costs – whether the team is comprised of one part-time support engineer or a full-time team of 5. It is definitely more cost-effective than having your lead developer answer the phone. But make sure to partner with a firm that can interface with you locally. That way, you won't need to be on a conference call at 1am.
  • Look for flexibility. Find an agile partner that can easily ramp-up or ramp-down the size of your support team as your support demands change, even if it fluctuates month to month.

By freeing up your developers and building a small, yet tailored support system, you empower maturity in both your product and your support infrastructure. And that is something that is scalable to a million customers.

When to Offshore and When to Stay Home

It's a pretty well-known fact that utilizing offshore development resources can be a great way to achieve cost savings and scale when it comes to technology development and support. There are also well-known risks in getting technical work done halfway around the world, including communication and project execution challenges, technology differences, language, culture, and intellectual property risks. Some of these risks can be well-mitigated by using a hybrid model, keeping some client-facing work local while the offshore execution team works on specified tasks. Yet sometimes, even this hybrid model won't work.

Challenges with offshore execution are often a result of the type of project that is being outsourced – not necessarily an issue with the concept of "offshore" itself. V1 development efforts, for example, are not typically good candidates for offshore development. With a brand new product, it is usually best to keep the initial v1 design, prototyping, and client interactivity in a local conference room with an ample stockade of caffeine and easy access to real-life users. On the other hand, the following projects can make for great offshore development material:

  • Projects where onshore resources have been used for the initial version, and new versions have specifically established scope and schedule.
  • Projects where user scenarios are well-understood, agreed upon, and prioritized.
  • Projects where solid and trusted customer relationships are in place, enabling ease of communication and quick feedback when needed.
  • Projects where key performance metrics (KPIs), are established for both the product and the offshore team, allowing for measurably improved delivery over time.

If these elements are in place, moving your technology development or support effort thousands of miles away is well-staged for success and can save you a lot of dough.

The Missing Link in Security Consulting

It's true - some businesses don't think about security until someone breaks into their store, information gets compromised by an insider threat, they are the victims of a zero-day attack, or a sudden compliance concern pops up. That's understandable – sometimes, day-to-day business operations and activities that drive profitability will naturally take precedence over the preventative care of infrastructure. Yet at some point, security will become an inevitable concern. Then what?

There are oodles of companies out there that can confidently walk in and analyze your networks, connections, access points, and every bolt and screw that makes up your infrastructure. They will then deliver compelling security gobbledygook that will, quite possibly, address all of your technology-related security concerns, and will undoubtedly be extremely useful.

Yet there is a missing link that many of them miss. Security is more than a technology and infrastructure concern. Breaches in security can pose a significant threat to the business itself. So when you are looking for a security partner, look for one that conducts methodical and ROI-focused business threat analysis prior to the more typical technology assessments and remediation efforts. By doing so, you can protect the very operational business concerns and profitability activities that had kept you too busy to perform a security assessment in the first place. This is the only way to keep your business protected along with your networks.

Building a Great Prototype

So you've got a great product idea. It's time to start thinking about turning those scribbles on a whiteboard into a solid prototype, and dazzling product. Yet – beware.

Prototyping efforts can be extremely seductive. They can undoubtedly get creative juices flowing. Yet technology prototypes are often shaped by the available tools, rather than by user needs. The resources needed to work on the prototype can take your group's focus away from the business problems at hand. And worst of all, developers can easily find themselves caught up in an endless loop of refinement. Prototyping, like most things seductive, can get expensive.

Not prototyping, however, can have significant costs in terms of true usability. Apple is the king of this principle – in fact, in its User-Centered Design course it says you can follow every guideline in their Human Interface Guidelines manual and still have an unusable interface. They go one step further and argue that every good user interface violates at least one of those guidelines. Their advice? Stay tightly connected to the real-life user. Involve the user early, and involve them often. Not prototyping can also cost you big time in terms of competitive positioning for your product.

A great prototype demands great expectations. And those expectations need to be clearly defined. Those expectations can actually drive what type of prototype you should build. If you have a business workflow problem, you may need a functional prototype. If you have a technology need, you may need a technical prototype. If you need to visualize a potential product that would empower cross-functional teams (including geeks and non-geeks), you may need to build a proof-of-concept.

Prototypes, like children, need limits. A prototype should never become an actual product. The initial functionality needs to be scoped tightly in order to protect your productivity and bottom line. In the case that you are embarking on a huge, multi-year product effort, an incremental prototype model should be used in order to minimize cost overruns and efficiently utilize user feedback.

Idea Entity teams thrive on driving creativity – yet specialize in building business-focused prototypes that are grounded in real life.

Making Product Ideas Real

So, you've got the greatest technology product idea ever. You're trembling with excitement. But do you have what it takes to execute it? Sure, you may have the idea, the energy, and might even have a business plan, budget, and buddies all lined up to help you. You may think you are well on your way to quitting your day job and owning an island. But do you really have what it takes to get to the finish line? There's a lot to do when it comes to making that idea real. Here are a few things you shouldn't leave out.

1. Research Smart. Nothing will cost you time and money faster than ambiguous, disorganized research. But good research, that is aggressive, precise, and business-focused, is critical to product success. When done right, it should illuminate whether you're the first to market, who your competitors are, who your customers are, and how much you should charge.

2. Find Your Cash Cow. Knowing what your revenue model will look like is not only crucial for driving initial investment, but it is also a major contributor to the long-term market success of a product. Knowing whether your revenue is going to be based on a niche user base, with a lump price or a subscription model, is important. Or maybe you're going to give the figurative "milk" away for free – and instead go after massive traffic or a huge user base, where you'll eventually make money on ads or entice secondary interest in that user base.

3. Look at a Map. A vigorous product roadmap can drive specific prioritization of features and drive market-focused versioning. While your creative juices might be in overdrive, it is unlikely that every shiny feature you want will be in a v1 release. But it is important to define what needs to be in that release, and the next, and the next.

4. Beware of Superhero Syndrome. While you may have come up with the idea alone, you will need some help getting it into the hands of your customers. You'll need a partnering integration plan that considers all aspects of your product's specific supply chain and distribution needs.

Finding an energizing, trustworthy strategic partner that understands your constraints and shares your passion can be tricky. That's where Idea Entity can come in. Making ideas real is what we do.