What Comes First, Project Planning or Requirment Analysis?

Question

By first, i mean i have read articles which puts project planning as the first phase of the sdlc.

In my opinion it should come after the requirement analysis and specification, because if you dont know the reqirements of a project, how can you plan about it?

it does not make any sense to me.

you're planning for a project whose requirements you don't know, it simply stupid!

Answer 1

Both.

The idea of "planning" as a step you do once in your project and never afterwards is pretty unrealistic. Planning is something you will do before requirements analysis (for exactly this step), you will do it afterwards, you will do it again whenever you reach a certain milestone in your projects and maybe between milestones.

Don't take models of the SDLC too literal, they are models, which are approximations of reality at best, not reality.

Answer 2

Requirements come in many forms. Regardless of what the project requirements are the company may have requirements about time and staffing that don’t change just because project needs get in the way.

It can seem unreasonable but leaving company needs unmet can leave you without a company.

A lot of the dark magic here is finding a way to match up both kinds of requirements. It can redefine what the project really is.

Answer 3

Requirements can appear, change or disappear at any moment during the life of the software.

---

It is worth noting that the life of the software is not the same as the life of the software development project.

The life of the software begins as a concept. An idea is somebody's head. This idea, may or may not come from a problem or a necessity. And while it is in the head of that person, it is getting its first requirements.

The life of the software ends when (nobody uses it anymore and) it is forgotten. Once the software is forgotten, we can be certain that it will have no more requirements. The software may or may not have new requirements up until that moment. If the software was ever used, but the users moved on, it was because the software was no longer a good fit for its requirements.

---

It is also worth noting that the life of the software is not the same as the life of the system. A system may include no software components. It may include many. And yes, it may include only one. In fact, the number of software components involved may change during the life of the system.

Some software will be used for multiple system, and continue its life beyond them. Some systems will outlive its software components, perhaps by replacing them as needed.

And hardware components, and peopleware components.

---

If a company that has decided they want a software (likely because they have a problem), they need to figure out if they are going to license some third party software or start a development project (I'm bounding outsourcing here). To be able to decide if a third party software fits what they want... they need some crude requirements (e.g. inventory management software, must run on Windows, must be accessible via intranet). And in the process of checking software, this the list requirements may grow.

Then, when they green light a software development project. They already have some crude requirement. They may even ask for an estimate, but let us not go that path, or I will end up in a rant.

Thus, before the project begins, the software exists as an idea, and it already has requirements. Then comes scope management and planning. Some features to work on are selected, resources are assigned to activities... including requirements engineering. At the end of the project (hopefully) a version of the software has been produced (by whatever methodology).

Requirements can appear, change or disappear at any moment, including before planning, during planning, and after planning. It is the job of the requirement engineering activity (phase or not) to collect them, document them, and analyze them.

Well, it is unlikely impossible for the first version of the software to be perfect. What is likely is that there will be a new project, which will produce a new version. Meanwhile, the developers had some ideas that they want to incorporate in the software, the users came up with some suggestions, and bug reports too... those are more requirements.

Maintenance might be a phase in the life of a software. It isn't a phase of the project. You do projects to maintain the software. See also Change Management.

Thus, we have more requirements for the project of the second version. We do planning based on that, then more requirement engineering (along side other activities according to whatever methodology, with its phases and such), and we produce a new version of the software along the way.

And repeat for every subsequent version. Or forks, or whatever.

So... were there requirements before planning? Yes. Did we do planning before requirement engineering? Yes.

Answer 4

Chicken meet Egg, Egg meet Chicken.

Any plan you develop without understanding the requirements will be a poor plan by nature. It has no hope of being that grand well developed plan where the unicorns frolic, rainbows end, and nothing is out of place.

It will however beat the pants off no plan. Because with no plan, how will you choose your next action?

The trick is to avoid making a stupid plan.

• A stupid plan is a plan that refuses to revise itself, particularly when new information is discovered (such as new requirements, or noticing a huge hole in understanding).
• A stupid plan is wilfully blind pretending that everything is known, that there are no uncertainties, no problems, no hidden traps. It seeks to authoritatively define the world.

What this means is that a non-stupid plan will evolve as requirements are analysed, as the goals are pinned down, as problems are identified. A non-stupid plan is humble enough to admit where there are uncertainties, where there are unknowns, and to not promise a result it cannot reasonably support (and when it is discovered that a promise must be broken, to inform all parties of the break).

Answer 5

It is not stupid, it is shameless.

You sell an optimistic planning to your client. He accepts your offer and you start working. You do not make the target of course but you can show something that provides enough hope to your client to cling to. Something that will make him understand that starting over with a competitor will surely take longer still than sticking with you and allowing you more time to get the product in a workable state. Now you and your client are in the same boat.

This is how market leading companies typically reach the top. A truthful perspective is just not marketable.