Three Components of a Successful Project

Earlier this month I attended the monthly meeting of the Seattle PHP Meetup Group. In ways I didn’t expect, it was a very interesting meeting. The content itself was interesting enough (we were talking about database design), but what I found even more interesting was how the meeting dynamics provided a good reminder of what goes into a successful software project. What I observed was nothing new – what I have to say will all be familiar to anyone who has run successful software projects – but my observations served as reminders of some of the key components of a successful project.

First, a little background…

Back in December, one of the meeting organizers, David Malouf, suggested a group-wide project that would drive our meetings for the next several months. He outlined a very simple data-driven application that we, as a group, would build. The details of the application aren’t important here, but the fact that his idea was simple is important. The members in our group have widely varied backgrounds – everything from complete hobbiests/newbies to professional, very experienced developers. Building a simple application would allow newbies to have insight into the complete application development process (without getting overwhelmed with finer points) while allowing those with experience to share best practices about the various stages of the process.

I have to say that I think this idea of a group-project is an excellent idea. So far, it has given the group a very real backdrop against which to have conversations about OOP vs. procedural programming, model-driven development, UML, class design, and tools that can assist with all of these. Most recently, we talked about database design, designing for the future (i.e. scaling), database abstraction, and (again) tools that can be useful. Newbies have had a chance to see the beginning stages of building an application and how the many decisions in such an endeavor are weighed. Those with experience have been able to share and debate ideas while gaining even more experience in leading and presenting to a group. The path ahead contains lessons in actually writing code, maintaining a code repository, collaboration, etc. The list goes on. This experiment is young, but I would highly recommend it to any group as an excellent learning experience.

And now for the the reminders about what it takes for a project to be successful…

One of the problems our group ran into in our last meeting was this: we couldn’t settle on a database design because we ran into analysis paralysis. We talked about simplicity vs. scalability. We talked about performance and maintainability. We talked about normal forms. We drew sketches, erased them, drew more sketches, and erased them. And, at the end of a 2+ hour meeting, we had no database design (for a very simple application). From a certain point of view, this was great – this is what  Meetups are all about, right? We had learned a lot about database design, even if we hadn’t settled on one. Well, I would agree if we weren’t actually trying to build something. We could spend the next year’s worth of meetings debating the design for this database and never get to the application (which, IMHO, is a goal that stands to provide a richer learning experience). This is a potential problem that any software project faces, and certain things need to be in place to make sure that you, the development team, are forced to make the tough decisions that will ultimately lead to a successful project. Here are some of the components of a successful project that I was reminded of:

1. Make sure your client’s requirements are clear. Part of what bogged us down was that the requirements of the application weren’t clear. In retrospect, this is completely understandable. David, our organizer, conceived the project largely as just that, a project. When we started throwing around database design options, we came back to him with lots of questions – questions he understandably hadn’t thought through. One thing David is doing between our last meeting and our next is figuring out exactly what the requirements are. He’s actually playing the role of a client. (For a more in-depth look at what it means to be a good client, read Cal Evans’ blog series: Six ways to be a better client for your developer.)
2. Have a clear timeline. Even with clear requirements, I think we could spend the rest of this year’s meetings debating database design. And, if not database design, then some other aspect of the project. But, with a clear “ship date”, we’ll be forced to make tough decisions – we wont’ have the luxury of exploring every option. At the end of the day, as with real projects, we’ll have to deliver something.
3. Have a project manager capable of making tough decisions. Healthy debate and exploring options is fundamentally important to a project’s success, but without someone designated to make sure we are honoring the client’s requirements and that we are on schedule, the risk of analysis paralysis is still great. There will be times when someone has to say, “Thanks for all the input. This is what we’re going to do...”

These are by no means all the elements that go into a successful project. They are, however, elements that we will have to consider in our group project. And, I think including these elements in this educational endeavor  will bring new insights into what it takes to build an application.

What do you think? Comments on any/all of the above are welcome and appreciated.

Thanks.

-Brian

Share this on Twitter

Comments

• Anonymous
  February 14, 2011
  Make it usable. =^)Great job here Brian!
• Anonymous
  February 14, 2011
  whenever a client tells me their idea is simple, i immediately believe it is likely not.  in my experience, they say so because they want their project done quickly and/or cheaply.  it is not the client's job to decide whether a project is simple or cheap.  all they can do is give a budget and a timeline, both of which help to define the project.
• Anonymous
  February 14, 2011
  Like it and very simple
• Anonymous
  February 14, 2011
  @darcyGood points. But, for the purposes of an educational group project, do you agree that the basic idea shoud be simple? That's the point I was trying to make about the project idea being simple.
• Anonymous
  February 15, 2011
  The comment has been removed
• Anonymous
  February 21, 2011
  The third point is the most crucial. Having a project manager that calls it down the middle and acts not just on behalf of the customer but also supports his staff is required especially during the often stressful delivery stages of the project.http://code.rkevin.com
• Anonymous
  September 16, 2011
  thnkx for d information..