How to start a development project when there are too many potential stakeholders

Question

I've just taken on a new job at a college as (the sole) Web application developer.

The college has a number of disparate but all pretty badly coded legacy systems. Mostly built in PHP they deal with things like attendance, exam results, marking etc.

My first job is to build a system that incorporates a lot of this data, which is currently resting in various databases without any kind of friendly API to pull it out (the existing systems are coded in vanilla PHP with no separation of data and view) with a new platform for recording pastoral information about students and presents it to tutors and senior staff in a useful manner so they can react to issues with students quickly.

In our first meeting, there were 18 people! There was no clear leader or voice that represented the majority. No identifiable client. The meeting swung from detailed implementation ideas on minor features from heads of faculty to arguments about whether we should use Excel spreadsheets or not for data input!

As you can imagine my head was spinning at the end. I actually had a lot of good ideas but I couldn't get them heard. This is a very new role for me, before I was part of a development team in a marketing agency. We had very well defined roles: Project Manager, Client, Designer, Developer.

I'd like to know if any seasoned developers or managers out their can give me some pointers on how I can whip my colleagues up into something that resembles a project team. Is agile the way to go? How would you approach handling all the disparate voices? It's clear that some process needs to be put in place very quickly, I'm just not sure what that is.

Answer 1

I would not expect any "agile development process" here as a solution to your current problem. First thing for you should be: clear your mission. That means:

• clarify what your own responsibilities are
• clarify what the responsibilities of the other stakeholders are
• identify who is responsible for each of the legacy systems
• if there is no client (yet) for your web application, find one who is going to use it in the future and ask for permission to incorporate him as a representative user of your system (a person you can discuss the requirements with)
• if there are different stakeholders with different goals, collect their requirements (for example, by interviewing them one-by-one, not 18 people alltogether in one room). Write the results on a list. Afterwards, start priorizing.
• write down a roadmap (the big picture) and a small spec for release 0.1 and make your boss as well as the representative client agree to it formally
• EDIT: see GlenH7`s comment

This can take a while, you will probably don't write much code at this stage of the project. In such a situation, you should do some "requirements engineering" first. But start small, think big. Once you have developed your first release, you will have something to show around, discuss requirements again with the stakeholders etc.

Answer 2

Separate the ones who really want this project to work from the herd.

Due to a lot of politics, someone put together this meeting with a list of attendees where the membership was determined by who would get the most upset if I don't invite them. It happens. This goal was fullfilled but as the developer, you found that nothing was decided. No one was assigned what to do. If you're lucky, they managed to schedule the next meeting or god forbid, they set a reoccuring meeting on the 3rd Tuesday of each month.

Next will come the formation of committees, sub-committes, and task forces. This is betteer, but you'll find them all equally worthless.

Finally, you're going to find out who really cares about this project. Who really wants to put in the time to do it right. Hopefully, this person(s) will have a supervisor that will allow them the time to do this and not just make it another item on their already lengthy todo list. Find these people ASAP! Help them manage their boss's expectations and get an agreed amount of commitment.

Get something in front of as many people in the original group who will even bother to return. They may all be smart and/or educated people but they're not going to read a bunch of specs. They'll like some things, hate others and want more. It doesn't hurt to write down suggestions, but try to get that party to follow-up with some skin in the game. Don't promise to do everything. Just address what can be done in the near future.

If you end up having to deal with more than 5 people on a regular basis, it's because some manager made several of their people get involved who don't really want to be there.

Answer 3

Come up with a list of ideas which you think would solidify / improve the existing systems based on your observations and their "needs" and ensure you focus on where you can achieve actual visible gains. Include on that list each idea you think would be useful, as well as any standout "reasonable" suggestion from the non-devs.

Build a feature list of things that "should" be included in your development efforts. Give each member "voting" power, maybe in the form of "sticky stars" and find out what the whole actually wants by each member placing stars next to what they think is important. Some people may end up with more stars if they sign the check, have final say, etc.. After that hopefully you, and everyone else, will see what is important to the whole, and hopefully they will agree to the priority, which will then translate into a roadmap

1). Survey the Team - Find out what each member considers important / needed / top priority

2). Get something out there, quickly - Dont try to solve all of the problems all at once, get the "bare minimum" functionality out there and have them approve, then collectively advance it based on feedback of the users.

3). Use their feedback and the feedback of other users to guide the development process

(Build, Assess Feedback, Build, Assess Feedback) Rinse and Repeat.

Also, you might consider putting "effort points" or estimated hours to complete.. that might also aid in prioritization.

Answer 4

Your first challenge is to identify the need for this project. Hold another meeting with all those folks and ask them to write down the problems that need to be solved. Don't let them talk about the many ways in which this project will be the solution. Force them to truly identify the needs/problems.

One way to do this is to ask them each individually to document those needs on sticky notes -- one idea per sticky. Then run an Affinity Diagram to help them group those disparate ideas into specific needs. Finally, make them vote (Multi-Voting) so that you can see the biggest needs.

Agile reminds us to tackle the feature that has the most customer value first. Start with the biggest need and then keep splitting that item down until you have the first small piece that you can actually do in a short period of time.

Answer 5

KISS - Make an itinerary. Thank everyone for coming, review it, do it. Side tracking will slow down if you address it by sharing their concern and ask them to stay AFTER the meeting. Make decisions by vote where there is controversy to keep most happy. Motivation towards participating in any system is directly related to the individuals belief in it's methods.