How can I ensure our project gets developed successfully, without having any project management experience?

Question

I'm a web developer who is part of a three-man team that has been tasked with a rather large and complex development project. Other than some direction and impetus from management, we're pretty much on our own to develop the new website. None of us have any project management experience nor do my two coworkers seem like they would be interested in taking on that role, so I feel like it's up to me to implement some kind of structure to the development process in order to avoid issues down the road.

What can I do as a developer without project management experience to ensure that our project gets developed successfully and avoid the pitfalls of developing a project without a plan?

Answer 1

There's a simple advice I can give you:

Do one thing at a time, and do it right.

Split the whole shebang into chewable parts (things your team can do in a few days) and focus on one part at a time only until this part is done. And by done I mean that it has been quality tested and is properly implemented. Avoid doing many things in parallel, for it will cause a buggy mess and you will probably miss deadlines because with such development practices, when you think you're 90% done, you've not even reached 50% and probably have a low quality.

Track the parts in a Ticket Management system or an excel list, for a small team, that should suffice for a start.

Personal advice I want to give you:

As the Team Lead, don't act selfish. You're all sitting in one boat and you need to work together.

See this link for further information.

Answer 2

Well, the conditional probability of your project succeeding given the information in the question - isn't good. However, it's far from impossible to succeed and there are different degrees of failure, and you probably have a fair amount of control over the degree of success.

In addition to the ever present risk that you just don't implement very well, you have to manage things that are probably bigger risks.

Developing without requirements is a really big risk. Do everything you can to find out the requirements. It doesn't have to be very formal necessarily, but get as much feedback as you can about what they want. Try to understand their goals, rather than only what they say they want, since you may at times have a better idea how to realize those goals than they do, and knowing their goals will help considerably in guessing when you have to guess.

Fail as quickly as possible. There will be times when you are wrong about what they want (or they will - sometimes what they asked for won't be what they want), so fail as cheaply as you can. A question is cheaper than a screen drawing, which is cheaper than a spec, which is cheaper than a prototype, which is cheaper than a fully implemented UI connected to a mock model, which is cheaper than a full implementation.

Do things in order of priority. When time suddenly starts running out on you it may be possible to get by having only 30% done if it's the right 30%. This probably means your pet features won't make it. Note that 30% of the features 100% done (tested, documented if documentation doesn't get tossed, build-able, deploy-able, etc.) might work, 100% of the features 30% done is a boondoggle. Finish all of each feature. If you are working with outside QA, documentation, marketting, whatever, get them in as soon as possible since that's effectively part of being 100% done.

Usually the actual development process isn't too hard to work out on a team of 3. It's working with everyone else that usually is tougher.

Sadly, one more thing I'd be remiss not to mention - cover yourself. Get what you can in writing, and when you have a verbal discussion send an email summarizing what you believe was agreed upon. You are going to be really busy trying to get this project done, and if it isn't a success and people start looking to hand out blame (hopefully your company doesn't do things this way), you won't have as much time to play politics as most of the other people involved.

Something more productive you can do to cover yourself is to set realistic expectations and try to keep everyone up to date on your progress. Don't try to hide problems. Give management the chance to change direction if things aren't going as planned.

That's a bit of a grab bag, but there are books written about this stuff. You could start reading some of them if you have time.

Answer 3

There are some things you need to consider:

Your Time - how much time will you really have to manage the project along with your programming responsibilities? There isn't going to be time for formal training, but that doesn't mean you can't develop something that is better than what you currently have (Which is nothing.).

Team Buy In - You're not in charge. Even if you were a certified PM, you're working with a team that is going to "need" planning for the first time. Hopefully they recognize that this project isn't like the others (they each worked on small projects on their own), so a plan is in order. Discuss what are the problem areas and how much everyone is willing to contribute. The first step in solving a problem is recognizing you have one.

Communication - Are you going to have regular meetings? How much documentation of specs is everyone willing to create and maintain? Will everyone just email you what they are working on and you'll update the project plan or will everyone learn how to do their own entries? What is management going to expect? Do you have to do a presentation or submit some type of schedule?

Start with a project milestone that is reachable and will give you some idea of how fast your team can build this thing. Avoid trying to come up with a final date too early. Your team has nothing to base an estimate. Get something working and go from there.

Answer 4

You're actually dealing with two separate issues - development & project management. One is about the actual work being done (dev), and the other is about making sure that work is done in the right order, on time, etc. (pm)

The development part I'll assume you have pretty well covered (you know how to dev software) since that's your job.

For the pm side, it's really not that difficult, regardless of how some pm's make it sound. Just remember that planning is 90% of the battle. Spend a big chunk of your time up-front breaking the project down into manageable, understandable pieces. Figure out how long each of those 'should' take, and what order they go in. Walk through the process with your other team members and talk it through, look for potential issues, delays, roadblocks, missing info, etc.

Then start working according to that plan and tracking progress. Keep in mind that no plan ever survives in it's entirety - things happen. The plan is a map, not a rule. So keep an eye on what you're doing doing, and adjust accordingly with an eye towards getting back to the original plan.

Good luck.

Answer 5

First, I firmly believe that every project needs some kind of version control. Bitbucket allows free private repos, so I would use that to host your code.

Second, every project needs some kind of structure. You might consider running your project using Agile principles--if so, I recommend reading "The Art of Agile Development" as a starting point, and asking your coworkers if they are willing to buy into that methodology. Obviously, with just three of you, certain things like pair programming aren't going to work, but other ideas (like a card wall) might work well.

I recommend using something like XP for two reasons: first, it's really easy for the team to see where they are. Second, it's really easy to communicate to management where you are. Other advantages include having a common vocabulary to achieve agreement: rather than say, "I'm going to futz around with jQuery for a couple of days", say "Let's run a spike to investigate jQuery, timeboxed to two days." That work gets captured and documented, which is helpful.

But regardless of what project management technique you decide on, try to stick with it long enough to know whether you need to change it, and get as much buy in from your team as you can for whatever project flow you come up with. Since you aren't their manager, you need to all reach consensus before anything can be done anyway.

Answer 6

On top of the excellent suggestions in the other responses, I believe that scope management is a critical factor in success. It is unrealistic to say "Absolutely no change is permitted" to your scope, but it is not unrealistic to set up a process that must be followed to allow changes to the project to be accepted. Every change should be subject to:

1. Prioritisation
2. Evaluation / Challenge / Justification
3. Analysis
4. Impact Assessment
5. Estimation
6. Agreement on the above by yourself and the client (management, in your case).

Try to implement something early and often - whether using Agile in a formal sense or not - that's a great way to avoid scope change, as it is easy to replan a later phase and deliver the new functionality then. Also, avoid heroics. Recognise that if it would genuinely take x days to do y work, you should not expect to absorb z and deliver y + z in the same x days, no matter what your client tries to tell you.

Good luck!

Answer 7

You have more experience managing projects than apparently you are giving yourself credit for. We start project managing as a small child. We do more formal projects during elementary school and through high school. You do all kinds of projects around the house.

This so called formal PM profession and its training is a lot of putting a name around what you have been doing all along. Providing some formal techniques that, likely, you have already been doing but maybe not with all the finer techniques. This PM has been around since for ever and has been a job function longer before it ever became a named profession.

Pick up a PM basics book and have a quick read. It will bring a bit of formality to what you likely know to do intuitively anyway.

Answer 8

A couple high level thoughts:

1. Begin with the end in mind. Figure out what you need to get done. A lot of this is asking, not telling or demanding.
2. Put agreements and decisions in writing. Don't delegate the note taking.
3. Divide the project into manageable tasks, with clear starts and ends. (Turn the project into mini-projects)
4. Back in to the deadline. "I need this piece last. It will take a week. It's dependent on these two items, which will take two weeks each. This other piece..."
5. Be brutally honest on progress reporting. Things are either done, or not done.

After you've learned the hard way, you can review the Project Management Body of Knowledge. Without practical experience, the theory will be useless. (What to apply and what to avoid isn't just a theoretical exercise)

Good luck!

Answer 9

1. understand the project
2. gathering requirements properly
3. divide project in smallmodule
4. develop each small module by small team together
5. test finally
6. for any further modification or enhancement if client need recycle now this time fast
7. successfully deliver the project

Answer 10

Your team must be know about Agile Methodologies well. It can make your project done eventhough you just have small team.

I implement some method of Agile Methodologies like divide your project in small module ( backlog ) and create sprint backlog for each of it and sometimes I write about logic to get each of sprint backlog done.