Ask YC: Project Management?

I work on DoD projects with varying project reporting requirements. There are many methodologies and processes one can follow. I've experiences success with Capability Maturity Model Integration and Agile (others here have mentioned agile too). There's an ongoing "meeting of the minds" of merging CMMI with Agile in the defense space.<p>For estimation, learning a bit of earned value management system (EVMS) can be useful. There is COCOMO II for estimation, but I don't think you need to go there for small projects.<p>A book I've found useful is "Software Estimation: Demystifying the Black Art" by Steve McConnell. Its helped me.<p>The secret sauce is to find that knife's edge balance of infrastructure (accountability and management) versus flexible productivity.<p>Then there is always the Scotty Principle.

I have a similar problem. A lot of the time I merely find myself developing infrastructure instead of developing features. Part of the problem is writing in PHP without a framework (or, rather, a semblance of my own); a more significant part, I believe, is that I just really, really like building architecture. In that way, I'm probably being an architecture astronaut.<p>The key, as you've said already, is managing client expectations. At some point you must have given a timeline, given a prediction for how long you <i>thought</i> something would take you. At some point you must also have deviated from that timeline/prediction; mine, as far as I've identified it to, is being an architecture astronaut. Hence, the first step, I think, is to narrow the problem down to those deviations, and question why you're deviating so. The deviations may even be something useful or necessary. Rather, figure out what is breaking, then step back and look at the whole picture to see what needs to change.<p>Agile might be the answer here. At the very least, there are several very good ideas you can steal from agile to build your own approach to engineering.

Break each part of a project down to what you can do in one sitting. If any item on your list is longer than 8 hrs, you're probably going to miss it. Also, figure out how many of THOSE thing you can do in a week (unlikely to get 40 billable hours / week for me)<p>As a general rule, if I'm unsure of exactly how long something will take, I double it, and I'm usually very close, or over the high end. (I'm down currently to only adding 40% more time per each unsure item, which has been very close lately..not that I'm getting faster, I'm just getting better at estimating)<p>Plan time to make their edits (10-20% or more of the project, depending on the quality and robustness of the original spec).<p>Don't take on a project with a hard deadline you can't meet, you will make yourself crazy.

Usually, but that is because I have learnt to...<p>a). add a little extra time to projects to buffer myself.<p>b). not take on projects I cannot do (beyond my skillset).<p>c). interact with clients regularly with updates so they are in the loop, know what is going on, and constantly happy.

I've found that since moving to an agile approach with weekly/fortnightly deliverables, my estimates have become better and clients expectations are managed nicely. Clients can constantly see progress and can easily see how my time is going to be spent week-by-week. If new features are requested or problems hit, it's easy to communicate how that's going to effect the current timings and next deliverable.

Extreme programming offers a number of tools to manage your projects. Some important points: imply the customer by giving him access to the project state and to let him change priorities whenever he wants, focus on completing and testing the most important use-cases ("stories"), frequent "micro-releases", do regular demoes and acceptance tests to avoid bad surprises and integration issues at the end.