Decision making after planning phase?

Question

Ok please dont downvote because im serious about this question. I hope im asking this in the right place.

At programming school they are currently teaching us about project management. Instead of teaching us the classic waterfall model, spiral model, smart or other project management models they have their own which basically states that:

Decision making comes after planning

Now I personaly have a problem with that because I believe you should decide before you do the planning. I mean we should know our target system, the framework and language we are using and other factors. Not doing any decision making before the planning phase either means the software becomes way too generic.

Answer 1

Now I personaly have a problem with that because I believe you should decide before you do the planning. I mean we should know our target system, the framework and language we are using and other factors.

If you're in a planning phase you should first pick up the requirements.

You may elaborate the pros and cons for specific target systems to realize these, and decide what should be used after.
This process needs to have some knowledge about the target systems, frameworks and programming languages in question of course.

Not doing any decision making before the planning phase either means the software becomes way too generic.

You seem to miss some steps here. Planning the concrete software architecture and components, comes after requirement analysis.

---

As from your comment the proposed phases are

1. Information Gathering
2. Planning
3. Decision Making
4. Realization
5. Testing
6. Evaluation

Phase 1 and 2 is what I got known to as Requirements Analysis and Architecture Design.
As mentioned that requires to evaluate some possible ways to go for specific target systems, frameworks and programming languages.

At the end of this phase, you should have at least two or more alternatives you can choose from.

Phase 3 isn't actually a "phase" but more a gateway into the realization phase.
At this point we decide which is the best way to realize the requirements by means of

• cost
• feasibility with the available personnel and their skills
• assessable time and efforts
• assessable ROI (return of investment)

At the Realization phase the software developers refine and detail the chosen software architecture model together with the requirements analysts and software architects.
This also requires decisions and team consensus by means of

• assesable time and efforts
• robustness against change requests
• overall maintainability

The Testing phase should approve that the realized software components meet all of the requirements.

Evaluation means to make acceptance tests with selected customers and approval if the use cases described in phase 1 and 2 were well selected and understood.

All of these phases should give some feedback to the former ones, and may require to make refinements and change decisions made formerly.
This can even go that far, that a project manager decides to "pull the ripcord", and the whole project may be stopped to prevent burning further money with a hopeless undertaking.

---

I've been and are in all of these roles for about 30 years now:

• Requirements analyst
• Software architect
• Software developer

Thus I know a bit of what I'm talking about, no matter what that thing is called at academia.
I've always just picked up the methodologies which best fitted my needs, and these might differ by means of scalability.
In any case decisions are made after former analysis and feedback, not beforehand.

---

_{At arc42 you can find some excellent material and templates to support this process.}