Planning in advance: Ch. 7 SG

Even thought someone might say that its impossible to plan before knowing which are the requirements, but… THAT ISN’T TRUE! There are several thing to do. More specifically, 7 things.

Project Vision

For a team to share a vision and final objectives (Objectives aren’t requirements), the team functioned effectively. This will make improvements in very aspect of the team; from organizational and administrative improvements, such as decision making; to motivation and influence on the team.

The vision must be specific and motivational, but the most important characteristic is that it must be achievable. Finally, everyone must commit to the vision.

Executive Sponsorship

This refers to designate the support that the team or person that has heavy decision impact on the project. This person or team will approve every feature, user interface, release…  And it’s important that if this entity is a team, each member must represent a different interest.
Because no one likes to have the same boss multiple times… Imagine the same reproach by each boss when you get something wrong.

Project Scope Targets

Features, schedule and budget are things that can and should be declared before any real requirements definition. Well… an exact definition of theses 3 things can’t really be done, but  a real tentative target must be defined. A recommended technique to define this sort of things is to define an upper and lower limit for everything, this provides a margin to deal with the uncertainty.

Publicizing Plans and Projects

Big mistake: TO KEEP THE PLANNING SECRET. People need and should know what are they going to face in the future. If the manager doesn’t inform the programmers or the testers, considerations might not be taken to make a plan that can adapt to them. So, because there isn’t a plan that they approve, or at least that they can prepare for, people run out of control. What should always be public? You ask:

• List of tasks completed
• Defect statistics
• Top 10 risk list
• Percent of schedule used
• Percent of resources used
• Status reports given to upper management

Risk Management

Every project must commit to risk management. What does this mean? Well, to provide the all the necessary means to predict, act and resolve risks. What should be provided? An approach, resources and funds, and make the assessment of risk impact the project (I mean, if you know something is coming, let’s act on it). And which are the approaches available? Here, have a list:

• Risk officer: Spotter of emerging risks. A «pessimistic» person that will try to find every possible problem during development.
• To 10 risk list: A list, with possible risks and how is currently being fought.
• Risk tracing: A system that prioritizes risks, if they are open or closed to process, and who is working on them.

Remember that each entry of the top 10 risk list needs to have a reason to be there. Answer why is that a risk and needs management, how is it going to be resolved, what steps are needed to solve it, who will do each step, when can a step be started, how much is going to cost. The answers need to be recorded.

Oh, and there can be a channel, available to everyone to report risks. The managers and officers can’t see everything.

Personnel Strategies

Basic knowledge to staff buildup: Senior staff at the requirements stage, add more staff to the development stage. And just because you need staff, you shouldn’t hire available people, you need to hire good and skilled people, even if that means to wait a little bit.

The team roles (For you to remember) are:

• Project manager
• Product manager
• Architect
• UI designer
• End-user liaison (interact with users)
• Developers
• QA/Testers
• Tool smith (develop utilities for the development)
• Build coordinator (running daily builds)
• Risk officer
• End-user documentation specialist
• Optional: Tiger teams (2 people temporary teams to solve problems fast)

Oh, and a last thing

Time accounting

Just… keep track on how is the personnel spending their time. OK? Good. This will help when making estimates, and presenting those estimates to the upper management.

And that’s it…

It’s a lot to take in. But when you do all of this, you have finally a SOFTWARE DEVELOPMENT PLAN.

Bye!