Projects often start because someone realizes that there is a new opportunity or that we need to fix something in order to save money. An idea soon becomes a requirement list and then the “innovator” convinces a manager that this might be something. The manager then contacts IT-people to get there view, what might the thing and what could be done. The “IT-People” realize that this is no out of the box solution, but this requires a unique system. The “IT-people” starts to write a specifications and talks to different stakeholder and then come back to the manager that first contacted team and asks “What if you add this and do that?” The manager answers “Ooh nice, can you also do this then” and so it continuous. And the specification just grows into a bigger plan. At this point the organizations seams to choose path to continue, either the plan-driven; phase by phase way or the agile let’s start solving some problems and see what we learn.
Now I’m probably a bit provocative but the problem but I think the plan-driven companies would probably end up with the right wrong system and the agile will probably just do it faster. The problem is that you are not solving and focusing on the real business problem, the IT-People have a tendency to start to focus on technical features. The most users will start dreaming up all kind of new features that you could do and be nice to have, but really doesn’t give any business value. Instead the most important thing you should do is to study users or future users how they would perform the action manually. Involving users early is a real key success factor, and then the important thing is to see what they really do and how they might use the system not what they think they might use and nice to have features. Cost savings driven project are more easily investigated. New opportunities driven projects are often more difficult to involve user feedback within, this is because people can’t as easy relate to something they don’t have experience with.
If you’re not a future teller planning is guessing. Strategy is about continuously choosing what to lay your effort on. A soccer game is 90 minutes long and if you run on every ball you will get lactic after 4 minutes. So strategy is about letting you team know what to put their effort on, which situations that helps us with our long term goals, so the team members recognize situations where it’s worth the effort. They know when everyone else in the team will join in and help you and at the same time know there role in the game. Some are middle field players the help get the ball up and are pushing things up the forwards. It’s the same in projects not everyone talks everything from idea through development and deployment. If you don’t got a strategy people will not be able to recognize situations where the whole team will come together with the whole team effort. People will run be able to judge the value of a situation. Better planning, as Mary Poppendieck (author of “Lean Software Development”) points out, results in a higher standard of living for the individual, for the team, and for the organization.
Creating a Project Plan
For all stakeholders and team members to create a mutual understanding of the project’s direction and goals, it’s a good idea to document expectations and the means for meeting those expectations. This is called the project plan.
Depending on the type of project, the purpose of the project plan will differ. If it is a very formal project, it is primarily written for the project client or product owner. The degree of detail contained in the project plan will depend on how formal and plan-driven the customer is and to what extent he wants these details laid out.
The Plan is Worthless, Planning is Everything
Plans are great for complex projects because they set the direction and the alignment of goals. However, the value of the plan decreases over time. Is it realistic to plan all activities upfront? Projects live in a world of constant change and new insights are gained so planning on a detailed level for a six-month timeframe isn’t practical for software projects.
This is one of the foundations of agile methodologies. For the short term, when an overview is created, detailed planning is helpful. But for the long term, a plan is simply to set direction. Discoveries about the project will be made, you become wiser from gaining all that additional knowledge and you change priorities.
The parallel to sailing
I’m a passionate sailor. I have spent my vacations sailing since I was a child. Each morning we plan where to go and what to do. We use charts to see what to expect during the day and which milestones we can establish to make sure we’re on the right track (milestones). When we start sailing we don’t see our goal (destination) so we rely on our milestones and compass. On windy days the waves splash against our boat and the sea looks dramatic. Looking beyond the horizon, the water appears calm. Reaching our final destination is as dramatic as the enormous waves we encounter.
It’s the same with project plans. From a short-term perspective, you get an overview of the drama, but from a long-term perspective, you can only rely on your compass and milestones.
A common timeframe for detailed plans is 3 to 4 weeks. In Scrum, a common iteration is about 3 weeks’ worth of work. In the beginning of these three weeks, the sprint is planned in detail.
Projects are like sailing trips: changes occur often because of the need to adapt to changes in the temperature and oceanic conditions.
There are different ways to start planning the trip from A->B. It can be hard to cope with dependencies and the order in which things are done. A good step is to identify the whole work package in the beginning and then break it down one at a time. Brainstorming will facilitate project delivery. Another way is to start with the goal and go backwards. To deliver we need to submit our application to the AppStore at least 3 weeks before the “release date.” Another 2 weeks is required for testing and other related tasks.
Large and complex projects can be divided into smaller parts and be planned as single units. Milestones serve to monitor progress and allocate resources. A milestone should have a clear goal that is related to the project’s outcome. Milestones are essential in controlling projects. When combining activities with milestones you can make a critical path method, helping you to identify risks of schedule slip-ups if a milestone is missed.
Critical Path Method
Many projects fail to meet scheduled expectations because there is a timetable slip-up in an activity. The Critical Path Method is a technique that is used to predict total project duration and helps control project overruns. The method takes the different activities and relates them. The critical path can be identified, as well as identify the longest path where there are dependencies in relation to other activities (marked red in the diagram underneath). For effective control of activities, these are the ones to watch and monitor.
The traditional plan-driven projects are based on the traditional “iron triangle” of Time, Cost and Quality. All requirements have to be accounted for in the requirement phase and then the project is planned around the expected features to be delivered. The features are the first ones to be fixed, afterwards an estimation of time and costs in delivering those features is drawn up.
The Agile mindset, on the other hand, is to fix time and cost to manage a variable scope. This leads to the ability to hit deadlines both in the short and long perspective. This way it’s easier to focus on features that build value and to avoid building features that never will be used.
Remember Pareto’s principle – the old 80-20 rule. Vilfredo Pareto, an Italian economist, observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he also observed that 20% of the pea pods in his garden contained 80% of the peas. This is how he came to formulate this principle. In business, people say that “80% of your sales come from 20% of your clients”. So wouldn’t it be great if you could avoid building features that will never be used?
The difference between an incremental approach and an iterative approach is that the incremental approach does not require going back and changing things that are already delivered; the focus is only the requirements that have not yet been implemented. In the incremental plan, you don’t learn by the previous work, and the final product is not based on knowledge acquired during the journey. Here is a visual example of the difference between the incremental and iterative approach: