Suggestions on project planning?

Question

This is not a programming question per se, but here it goes. I am a senior CS undergrad, and I started an internship this summer for a mid-sized software company. I've done a few freelancing jobs before, but it's the first time I've been officially (more or less) employed as a software developer.

I've been asked to code an internal website from scratch to be used by separate teams in the company, and I've been given a lot of flexibility in designing it. And therein lies the problem: we've had several meetings and design reviews and everyone seems to have an idea on a new feature, and even conflicting ideas on how things should work.

So far my initial prototype has survived all of this, which is something I was told not to expect - but I knew I had a solid design. While I am not behind schedule, the work is progressing significantly slower than I had predicted. A lot of this has to do with loose specs and constant features requests and changes.

I am to deploy an alpha in a couple of weeks, which I thought wouldn't be a problem, but the way things are going I am not sure how that's going to work out.

Does anyone have any ideas? Thanks in advance

Answer 1

I'd start by locking into the features that have been agreed upon and place all feature requests into some sort of project planning software (OnTime Perhaps). Then roll out the Alpha release with the agreed upon specs before moving onto the "we'd like" and the "bells and whistles".

Answer 2

You need to prioritize and triage feature requests, possibly even some of the ones you have already agreed too.

Answer 3

You are asking a timeless question about (software) project management. There are careers made writing books on the subject.

I agree generally with rockinthesixstring on this.

If you don't have an effective project manager who can filter the customters' requests and manage their expectations, and say "no", then that will have to be part of your job.

Sometimes there is an art to not saying "no". Sometimes you can say it more like "As you see in the schedule, version 1.1 is going alpha next week. The feature list for version 1.2 is already set. I'll add your new feature to the top of the list for 1.3. But if you like, I can call a meeting with the other teams to see if we can reprioritize the 1.2 features."

As to conflicting ideas, if there is no other "decider", than that becomes part of your job as well.

Understand that not everyone will get their way.

Without an approach that addresses these sorts of issues you simply won't succeed by any measure.

Answer 4

It sounds like product ownership is not clear (as can be expected with internal projects with multiple teams). You should probably run some form of planning game. If you have multiple stakeholders, you might give them each 50 points to vote on all the features in an iteration. You, as developer, decide how large each feature is. The features with most points/size get into the iteration. If some teams are more important, give them more points. You should also spend some points yourself.

Answer 5

I would like to express my approval of James McLeod's post. The only justification anybody needs for wanting a feature is "user x might try to...". The difficulty is resolving contradictions between their opinions and somebody else's. The feature with a higher 'priority' as assigned by your project management process is the one that gets implemented, at the expense of its competitors if necessary. Ask the people suggesting features to go away and put something down on paper explaining the reasoning behind the feature and the circumstances they think might preclude its inclusion. Letting everybody else see what limitations they think their approach has could help break a decision deadlock. The feature whose case is stated more thoroughly 'wins'.