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.

2 Answers 2


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.



  • 1
    You're right, I wasn't describing a proper project. I need to break it up into scope and time frames to create projects. No wonder it didn't feel right to keep one open project and keep piling onto it. Thanks for your suggestions. Commented Mar 21, 2013 at 8:21
  • Glad I could help.
    – Josh Bruce
    Commented Mar 21, 2013 at 12:06

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.