Mar 20, 2009
Print this post
Picking a Project Management Methodology
We were having an internal meeting to pick a project management methodology for a web project we are working on for a new client. As developers of commercial software, our instinct was to lean towards an agile based approach where our process would be:
- Make an initial feature list
- Get time estimates on each feature
- Prioritize the list
- Time box the development effort
- Build and test as much as possible in that time
- Launch
- Get user feedback
This works great for a tightly defined set of deliverables and a client who has done software before. However, that’s not what this project is nor the profile of this client.
More than building features, this client is interested in having us take care of them. They are new to technology. They have a great idea, an understanding of their target users and the enthusiasm to stick with the project.
In their case, we are providing a full service consulting and execution experience. The application we’re building is the center of that experience, it’s the basis for the services we’re providing. But the scope extends way beyond building the application.
In this scenario, a waterfall approach combined with constant communication and flexibility is the right approach. Namely, the focus will be to:
- Understand the client’s vision
- Write a detailed, final specification through many iterations
- Brainstorm with the client
- Build according to the specification
- Launch an alpha internally for functionality and scope affirmation
- Integrate comments and changes
- Another alpha release -iterate
- Launch a beta for testing and scalability
- Bug fix and test
- Bug fix and test
- Bug fix and test
- Launch to the public
All the while, we will be educating the client on different facets of development, software, user experience and running a software based business. We’ll be having numerous discussions and creative brainstorming sessions. We will be delivering the exact product they want and providing the service level they’ve requested. The specification and the process itself become the foundation for the conversations and the subject, as it were, around which our conversations, services and deliverables will revolve.
Both agile and waterfall can be powerful approaches. It all depends on the context of the engagement. You have to pick the right methodology for the right engagement and the right client. As the dean of a local incubator said yesterday, it’s about finding the right fit.
Excellent article!
When a developing team is willing to use the methodology best fitted for the client, the end product and the relationship with the client will turn out much better.
Nice informative article.This methodology will be very useful to project developers team.
A very good article. It helps project team and alike. This methodology just fits what a team in the making should follow.
Nice article Mark. Both methodologies work well. Having a waterfall approach that allows for flexibility however needs to be carefully monitored because this could lead to potential scope creep and cost escalations.. but if properly managed it will work perfectly.