Last updated: Feb 28, 2021
Photo from Unsplash
This post is about my take on the first 3 stages of project management.
You have to find the best approach for your specific case, if your client doesn't seem to be too confident, maybe you shouldn't spend too much time designing up front, maybe the requirements will change.
At the same time you can't just start coding blindly because moving in the wrong direction is like not moving at all (unless you get paid per hour).
are the initial phase where you talk to the client about the website, the problems they're trying to solve, the business model, ideas, expectations, any domain specific questions you have, etc.
should be understood by anybody - they shouldn't include any programming specific terminology
could include domain specific terminology - i.e. logistics, law, medical. The programmer should ask any domain specific questions / assumptions. If you don't know what exactly you're building, it probably won't go well. The client maybe knows the domain specifics well, but most of the time they have no clue about programming, so they might have unrealistic expectations. The client is more likely to let you tweak the requirements if they see you're involved / interested in the domain, not just the programming part.
are formatted like:
are the first, dirty iteration of the design phase in my workflow - I've got the client's requirements and I can start thinking in terms of the requirement to implementation option mapping, in terms of pros / cons, based on the tools/constraints I have.
are programmer centric notes based on the collected requirements
include programmer terminology
include some things to think about in the future, in the design phase, considerations, writing down questions, thinking about the constraints you have, i.e.:
Xwould make implementing requirement
Aeasier, because reasons
Yis not suitable for implementing requirement
B, because reasons
is the perfect phase to talk to the client about changing some of their requirements, if you've seen flaws in the way they want things implemented.
This is my personal opinionated approach to the introductory phases of project management, in general I don't want to spend too much time planning in advance, because most of the time the requirements change. However I don't want to jump straight into coding either, because some decisions are very hard to undo as the project progresses - like changing database management system, authentication strategy, etc.
This approach is good for when you go back to a project you haven't worked on for a while - you can get up to speed quickly and don't have to read lots of documentation that might be outdated. The requirements in the form of intent are most often enough, for example:
X, because of reasons