Project planning: where do you start?
Planning to succeed requires a good plan!
The first step to make before starting a project is to work out an estimate of the effort required to get it completed. An efforts estimate gives you an number that represents the "amount" of time that a project will take to get it completed. Once that information is available, you will then face the next stage: project planning. Unlike the initial estimate, that is all about "how much work" is needed, planning is all about "how and when to carry out that work". You need a plan, which will allow you to take the project from zero, to something complete.
The basics of planning
There are several issues that needs to be kept in mind when dealing with project planning. These are not always obvious, even to the more experienced project manager.
Small projects might not even need formal project planning. This is especially true if the team members are experienced, have worked together before and are therefore going to know how to manage the time they have available. A formal plan might still be done in these cases, so that other people in the company can know what is going on; however, having it won't help the team themselves to get things done on schedule.
The variables are not independent: 100 people will not complete a 100-people-day project in just one day. This sentence sums it up: this problem is known as "irreducibility", and it's well known to project managements who found themselves in the situation of having a project that needs to be finished within an upcoming deadline, a virtually unlimited budget, and no way to actually meet that deadline. Projects are not like computers, where you can just throw more processing power to get more done.
Projects that go on for longer are more likely to suffer of scope creep. This means that planning a project allocating too much time for it will put it at risk. The reasons for this go beyond customers being unreasonable: technologies might change, or the needs of future users might simply mutate over time.
Team members' abilities change over time. When you plan a software project, you need to keep into account what team members can do so that you give them realistic deadlines. However, this is often an elusive piece of information, as workers' abilities change over time: they improve as they get more experienced, but might also decrease because of other circumstances (such as events that mine the ability to concentrate).
So, as a project planner you have all these elements, and you need to find the right balance and the best combination in each project. In the end, you have three main variables:
Each variable will be influenced by the many factors (see above), and things get tricky. With the wave of collaboration software, the focus shifted from complicated software that tries to predict absolutely everything, to team communication and collaboration. In collaboration software, the scope might be defined by the "task lists", and "duration" by the setting of predetermined "milestones". Effort can then be decided accordingly, and -- more importantly -- can be measured by using timers.
Why collaboration software works
Collaboration software is different to project management, as it tends to work on the principle that the "time" variable will self-manage, and that tasks are not strictly assigned to a specific person, but are 1) Bounced back and forth amongst team members 2) Discussed upon and worked on in a collaborative way. Once you have your project estimate, in classic project management you then need to decide "who" and "when". In collaboration software, both of them become very fluid: "when" becomes "when it's done", and "who" becomes "whoever is able to do it".
This means that:
There is no need to account for "slack" in your project management plan. Basically, you end up with a bunch of people with a bunch of things to do. People will most likely track the time they spent on tasks, but there is no strict need to account for slack since there is no set timeframe for a specific task (which could be completed by several people after bouncing around several times). Many see slack as a very dangerous concept: if they know they have it, workers will tend to use it, whether they need it or not. The only way to have them use it effectively is by not telling them that it's there in the first place -- which encourages a high stress work-situation, as well as a centralised manager who is the only one aware of the amount of slack available.
The plan can change easily. If a team member has a problem, or is unable to work on something, and her tasks are left as undone, other team members can easily take over and finish those tasks after getting valuable input from the original owner. This is what is called "dynamic modelling": the project plan is adjusted throughout the life of the project.
Projects are not seen in terms of a timeline with constraints, but in terms of "list of things to do" (as well as "done"), which is a much more intuitive way of looking at it.
Collaboration software for bigger projects
Collaboration software tends to work best with smaller teams working on small to mid sized projects. The nature of it implies that its team members need to communicate a lot, and trust each other enough so that bouncing a task is something done within reason, and woth good motivations.
This doesn't mean that collaboration software cannot handle big projects. It just means that bigger projects need to be broken down into smaller ones, which can then be handled by the same team, or (even better) different teams. The bigger projects can then be seen as tasks for the bigger picture -- a big picture which turns itself into a collaborative project, where each person is responsible of a specific task (even though bouncing tasks around in this context isn't exactly ideal).
- Project planning: where do you start? (main article)
- Project stakeholders (413 words)
- Project planning (241 words)
- Modularity and ERP (86 words)
- Originis of "ERP" (304 words)
- Features and components of ERP (101 words)
- Disadvantages of ERP (190 words)
- Connectivity to plant floor information (249 words)
- Execution of ERP (880 words)
- Benefits of ERP (133 words)