Ongoing Development and Maintenance: Should I break it up into small projects, or keep one open project and keep adding milestones?

Question

I have to manage ongoing development and maintenance of a client's web domain. There are many ideas for features to add in the future.

I was wondering what the best practice would be for an ongoing project. Should I keep one project open, and keep adding tasks and milestones for each stage of advancement?

or, should I just create new projects for each stage of development?

I'm wondering if a project will get too cumbersome if I'm continually adding more to it, and if it would be better to have smaller projects which I can close after completion. But, that leaves me thinking about maintenance on those closed projects.

PS: I'm using zoho projects if that makes any difference.

Answer 1

By definition, what you are describing, is not a project at all - because it has no defined beginning and end:

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. ~ PMI

There are, however, a few ways to turn this concept into a project(s). One would be to create a backlog of items from bug fixes to new features. Then pick a stack of them - wrap them in a time-box - and work on them until the end of the time-box. I hesitate to reference Scrum here because Scrum is pretty rigidly defined in its roles, responsibilities, and artifacts - but, it is how Scrum operates from a PM perspective.

The objective is to create a defined scope of work - then commit to a duration in which that work will be completed for it to truly be a project. If you divide your tickets into three categories this is pretty easy to do in a true "project fashion" - in situations like these I have used the following: new development, non-functional defect (the text is too far to the right), functional defect (stuff is crashing when I do X). Non-functional defects and new development are placed on a waiting list - because we need to wait for time, budget, and human resources to be prepared and scoped. Functional defects are worked on continuously and/or added to a project (the schedule should allow developers to be at about 80% or less capacity, depending on the stability of the system, to work on functional defects).

Basically, best practice from a PMI perspective, based on my understanding of the PMBOK - is to define a scope of work and time frame - at minimum; otherwise, you are not working on a project. From a more Agile perspective, best practice might be to throw out the concept of a project altogether and use more of a lean approach - tickets come in - they're prioritized - you complete those with the highest priority based on a due date of "as soon as possible". When the ticket is done, tested, blessed, you can either release a product update; or, wait, collect and integrate them into a more cumulative release at a later date.

Hope that helps.

---

http://www.pmi.org/About-Us/About-Us-What-is-Project-Management.aspx

http://www.amazon.com/Leading-Lean-Software-Development-Results/dp/0321620704

Answer 2

I would close the initial project. I would schedule follow-up "releases", that can each be their own project, defined by the scope of the features you are going to include in it, and bound by the beginning and end dates.