Why the MVP method is hard – Technical

This is the 4th and last post in the series about why the MVP method, as described by Eric Ries in The Lean Startup, is more challenging than it first appears. Many organisations, large and small, refer to it. In fact it’s sometimes hard to find product road maps or project plans that don’t make reference to an “MVP.” However, few are able to apply even the most basic tenets of the MVP method, and instead fall back on traditional development paradigms which results in what I call the MPP.

Previous posts discussed the organisational and personal obstacles to applying the method. Let’s look at the technical challenges. I find this is something that is often glossed over, Continue reading

Postpone technical details as long as possible, despite what your PM tells you

I’ve always been a firm believer that whether you’re Agile or Traditional, it’s important to postpone describing technical details as long as possible. It’s very tempting to start to solve problems ASAP, because there is something very satisfying about solving puzzles. Also, many project managers and others who are being held to deadlines will push to start design and coding as soon as possible. However, I believe in, as someone I met recently described it to me, a “back to basics” approach.

One challenge I often face is when a client pushes for me to start technical discussions with the users. Their argument Continue reading

Getting the Horse to Drink

Lack of stakeholder and user involvement is often cited as a primary reason for project failure and the greatest source of project risk. Unfortunately, whether you adhere to an Agile, traditional, hybrid or mixed methology, getting and keeping customers involved in the development process is always a challenge. I explained previously that the most common reasons customers state for not being involved are that they are too busy, they don’t trust the technical team’s ability to deliver, and that they don’t see the meetings as productive.

The first reason is generally beyond a project manager’s control, and the second is a lack of trust between stakeholders and IT that is often Continue reading

Leading the horse to water

In my last post I described 3 reasons customers cite for not participating in development. One of the reasons, and one that a project manager or business analyst can impact directly, is the customers feel that the meetings are not a productive use of their time. They feel the meetings don’t accomplish anything, take too long, or that they were unable to contribute and their presence wasn’t necessary.

I’ve witnessed many meetings with customers that I would describe as dysfunctional, and I’ve worked in many organizations where meetings with no agenda, no direction and unclear outcomes are the accepted norm. The focus Continue reading

Flattened Requirements Management

 (Originally posted here January 13th, 2012)

In 2003, Thomas Friedman wrote in The World is Flat how ten factors, which he called ‘Flatteners,’ have converged to create a more level playing field in terms of doing business, making it much easier for organizations in developing countries to compete with developed world companies in a number of industries. One of the flatteners is supply-chaining, which he describes as “a method of collaborating horizontally – among suppliers, retailers and customers – to create value.”

He predicted that in order for organizations to succeed in this flattened world, they need to learn to work closer and more collaboratively with their suppliers. Continue reading