Should software startups adopt a formal project management methodology?

This was the subject of a recent online discussion in LinkedIn’s Project Management Institute Group.

Without a doubt, my project management brethren (especially those who are certified Project Management Professionals) like to wrap every project in a formal methodology. It is something they understand and something they are comfortable with.

But my experience suggests that this oftentimes is not the best path forward.

During the past decade, I have worked at a number of software starts-ups. Each of these companies was developing products on the 'bleeding edge'. Because of this, the company’s ‘software programs’ (i.e. each product is, in actuality, a series of releases or ‘software projects’) were highly volatile - in terms of a number of factors including:

• Requirements - The product roadmap (we typically forecasted out 18 months) were in constant flux. Based upon a number of factors including, but not limited to: markets dynamics, customer feedback and sales pipeline.

• Complexity – Because we were building 'bleeding edge' products, our team had to resolve many technological unknowns - some of which were not apparent until after coding began and others which were not resolved until coding was in process.

There were other factors. But these two seemed to be the most critical.

I have found - that when developing software products - the most important thing is to establish a “rhythm” within the product development organization. By establishing a repetitive, consistent rhythm - everyone (product managers, engineers, testers, and technical writers) has a good understanding of what needs to be done/ when. This allows the team to work like a well oiled machine.

It is critical that the methodology chosen enables the team to move as quickly as possible - while at the same time achieve the company's objectives (in terms of features, quality, cost, and schedule).

The agile methodology – my favorite is Scrum – allows for the type of rhythmic development characterized by quick, iterative development cycles. In my opinion, this enables teams to better handle the gyrations caused by changing requirements and glitches due to technical complexities.

Of course, we need to be careful. Every project is different and one methodology that may be appropriate in one situation may not be in another. As such, there are times when an iterative lifecycle (such as RUP) is more appropriate.

The Bottom Line – Whoever is leading the Product Team needs need to evaluate the situation, the team and the environment. And choose the methodology which will reduce risk and increase the likelihood of success.

While there is no one best methodology, there is a best methodology for a given situation.



Post a Comment

0 comments: