May 16th, 2006
In today’s world of Web 2.0 expectations, it is important to manage your project using Web 2.0 friendly methods and tools. For my money, that means an agile development process and using an agile friendly project planning tool. The best tool I found that fits the bill is VersionOne.
This HOW-TO will take you through the steps of setting up a project. I highly recommending the 24 minutes on the project administration instructional video. That will let you know WHAT the tool will do. What this article will cover is a recommendation for HOW you should set up your project(s). That how, of course, varies greatly depending on your company. I will cover two cases (namely the two I am most familiar):
- The start-up: In this case, the team is small (no more than 5), and there is no prior development. Project has not yet been started.
- Established small company: In this case, the overall development team is in the 25-40 person size. The company has one primary product with one or more versions in production at any given time and a support group supporting the existing version. Some projects are underway, others are not yet started.
Repeat these words: Keep it simple. VersionOne has A LOT of features, with many configuration options. You are a startup and every penny matters and you want to get the most out of your licensing fee. You will; but the key is to keep it simple.
Now, as a startup, your ONLY focus should be on getting a product into the hands of your customer. If you are successful, towards the end of the project you will have matured your processes and figured out how you are going to support the product; but right now those issues are a distraction. You don’t have a product yet, you don’t have customers yet, you just have one hec of an idea that deserves the best you can throw at it.
So, at this point, just set up ONE project. That project will be a child project to “System Project”. Later, as your company matures, you will introduce layers into the project structure, but right now, only worry about the one.
So, first thing you need to do is add your team members. Fire up VersionOne, and login as admin. Click on the Administration Tab:
Click on “Add Member”
Enter the team members name and login information. I would recommend setting thier default role to “Project Admin”. You are a small team and at this point, better to err on the side of flexibility and collaboration. Repeat this process for each team member.
GOTCHA: If, after adding the member to the project, you want to change their role on the project, this is NOT the place to do it. What you are setting here is their “default role”. This is the project role the system will assign the team member when you first add them to the project. If you want to change their role after they are on the project, do it from the Project Roles tab.
Ok, now it’s time to add your project. Click on the project tab:
Now click on “Add Child Project” to add your project as a child of “System”.
Create the project using name of product you are building. Don’t worry about releases. As I have said, simplicity is key. Pick two week (14 days) iterations. It is a good size iteration, and it will keep you focused. Uncheck “Share Parent Iteration”. You only want to check this box if you want the parent to have the overall schedule. In this case, we want our new project to have its own schedule. Click OK to add your project.
Now click on the Project Member’s tab:
Drag each team member onto your project to add them as members to the project. Your project setup is now done. Time to start planning!
With the team, brainstorm iterations and enter in iteration plan for the project. Go only as far as you know. Don’t guess. As you start executing you will learn more and refine your iteration plan.
KEY: Do not activiate iteration 1, yet. Brainstorm with team, enter in iteration 1 stories. Each owner should then enter either a place holder task OR actually task for stories. When everyone is done, activate the iteration, start the project. (Once you activate the iteration any changes and additions will count against you on your burn-down graph.)
The Established Company
Setup for the established company is pretty similar. The main diffence will be in the the project structure. When you define your team members, I recommend setting up teams leads (and above) as project administrators and everyone else as developers.
I recommend creating the following structure:
[Support Project 1]
[Support Project 2]
Set your schedules at the Release and Support (vs. Support Project) level.
Next week I will cover iteration planning.