By now you should have an idea about…

• what the goal and reason of the project should be;
• who's involved in the project, direct or indirect;
• within which constraints you have to operate;
• what you can and must alter, and
• some background to anticipate current behavior.

The next step is to determine what strategy the project should take. What kind of steps? In which sequence? With who? I'm not talking about a fully detailed description; "George will walk to the bathroom. George will take his trousers down." I'm talking about real strategy!

The 'traditional' steps within a software project are something like:

• we think about the subject
• we specify a solution for the subject
• we implement the subject
• we activate the subject in the organization.

In project management lingua we call these steps 'phases' and have cool names for them like 'analysis', 'specification', 'implementation', 'roll-out'.

At this moment you have to determine the 'phases', or mayor steps, you will take. A strategy would be to follow the steps as mentioned above (the 'traditional' one). You could do this, if what has to be done is absolutely clear and everyone agrees. If not, this is not the way to go. By the time you want to implement the stuff, what has been written in the specification is not valid any more, the people changed their minds. Because this is often the case, more common is a strategy where these steps (or some of them) are repeated several times. So, for example, instead of thinking for 6 months about a subject, and specifying a year, the project will go through several steps of 2 weeks thinking, 4 weeks specifying, etc. With every reiteration the specification gets more and more detailed, and you would benefit from the results of later steps.

The project strategy, like any other strategy, should be simple and logical; you must be able to explain it to someone not related to the project in 2 minutes. So, don't go rushing into methods and the technical talk, like incremental, spiral, tornado, waterfall, it is only camouflage for when you have no idea what your talking about.

If the goal is very unclear, the scope is totally undefined, the strategy would be to

• first get the goal clear,
• determine the scope,
• adjust the project according to the outcome of the previous step,
• execute the remainder of the project.

It's ok to have the later steps more general then the first ones. It is a very simple strategy, but you can explain it to everyone, and it makes sense. If you don't know exactly what to do, you first try to get that clear.

The strategy should be a result of all the information about the stakeholders you have collected. Consider the following situation. A chief of some users has a formal role in determining the requirements for the product. You, and some other people, fear that these requirements will go beyond the scope of the project. Intervening continuously with the user chief, may be considered as a threat to his independence or formal status. By creating some periodical steps to review the requirements in relation to the scope with stakeholders concerned, this problem can be overcome and result in the needed win-win situation. The decision of having these review steps for this case, is also an important part in determining the project strategy.

Related Links
Using Iterations
Method Components Have a Reason: Scrum
Agile Or Plan-Driven Project Management: One Size Doesn't Fit All