As a way of saving this for a personal consultation, avoiding frequent mistakes and helping people who are not used to exercising the project planning and management muscle, I've decided to write this post. This year, I related to many teams that did not have a programming background, because of that I was the owner and responsible for directing many projects, so I decided to write some of the lessons I learned from experiences I had. These lessons helped me to come up with better ideas, set better the project schedule and consequently succeed in implementing them.
When we have a team of engineers, these project planning responsibilities fall on product managers, product owners and so on, our job is to implement and have insights on how to make the process better. But in any case, having a good plan is essential for good engineering and good design, especially when you are dealing with complex or large projects.
Writing a document
So you had an idea started writing a document you shared with your colleagues, but you didn't get the feedback you expected, because your document might not highlight what you wanted or the way you wanted it?
You ask yourself, what is useful to have in a document so that you can convince and draw the reader's attention to the most important points? And you don't know what to do... I hope to answer this question for you like amazing people answered it for me
Goals
People need to have a clear view of what you intend to do, do it at the top of the document, so they will have this in top of mind while reading your entire text.
You also want to make it clear what things within that scope you want to cover, that is, it is useful to limit and explicitly write down what the project does not propose to do, it is probably also interesting to explain the reasons for not covering these other things.
Problem
It is important to demonstrate which problems you want to solve, so that people understand how relevant and urgent this problem is. It may be interesting to use some metrics or analyze what your team priorities are at that moment. Make it clear if what you intend to do will solve all or part of the problem.
Design
You don't want to go too far in discussing the solution design. It is useful to provide high-level design, so that it helps you and the people who will work on the project, you should stop writing when you feel that the details you are providing will not make it easier for you to build your solution.
Be extremely open to hearing feedback on this part (as well as the others), also make it clear what options you have considered and why you have not followed them. This avoids repetition of discussions and will likely cause you to focus on the feedbacks you need most.
Risks
While there are things that are beyond our control, it is important that you list and try to find out what can go wrong. After all, if the project is a success, the team wins. Take some time to reduce the chances of failure.
From time to time, double check to make sure your assumptions are still valid. Ask your partners for help. And have an alternative, if things don't go well.
Finally? After writing and discussing, stop thinking about risks or failures. Focus on solving your problem.
Milestones
Milestones are very important for people to understand how things are going or how long they will take. So write a series of milestones for the job, so they'll understand it easily.
Estimative
The estimate is certainly difficult to get right; many projects do not work for that.In most cases it is useful to talk to someone who has done something even remotely similar. Tell them what you are going to do and ask for their impression.
People
Record who were the people you requested feedback from and validated your idea. This is useful if you are stuck or want to align if you are heading in the right direction. Also list what that person does will probably be interesting for you to remember when and why you need them.
Certainly planning and defining a document like this requires hard work, probably it will be difficult to get it right the first few times, but as you train, get more practice and help as things will work out better. I hope I have been useful in some way.
Top comments (0)