Project Management Document to prepare for Technical Team Leader

Question

I am recently promoted to team lead, with this, my organization has also recently started to following the process of software development life cycle, but so far not too many things are streamlined.

Currently, I am getting Business Requirement Specifications (BRS) from the product team, and it is the base document we are using for our development. As a technical team lead, what document should I prepare before starting the coding(SRS, FRS etc.)? I like to use some new technology components and features in application, so how can I make sure that project development will work smoothly and doesn't collapse at the end movement?

Answer 1

I like to use some new technology components and features in application so how can I make sure that project development will work smoothly and didn't collapse at end movement.

I'm pretty sure that there isn't any documentation, which will ensure that the work will go smoothly. Usually, it doesn't go smoothly anyway, but using Scrum, DSDM, Lean or Kanban can help you to make it less risky.

If you cannot introduce a new way of working, have a high level documentation, which defines what has to be done, and let the team find out the how. Have a weekly discussion where you check on the progress and update the documentation if something interesting or useful comes up.

Over-documentation - which may happen in your case, because it is your first project and you don't want to fail - can kill a project. If you write down everything how the work should be done, the developers cannot really use their skills to deliver a great product. They won't bother with important details, because it is your documentation so the responsibility is yours. They will implement that is written down, and nothing more. Having a goal - the "what" - gives them perspective and the only thing you have to take care is that they are using the right "how". Instead of documenting this "how" be there with them and provide as much help as possible.

Answer 2

Using a Dev approach (or SDLC) is one thing, there are still some fundamental "Project" questions you'll need to make clear for everybody involved. A basic "Project Charter" or "Project Initiation" template can help. There are hundreds to be found on the web.

Based upon the description you gave us, some questions come to mind:

• Scope: you will get a BRS document. But will you deliver all requirements? What exactly is in and out of scope? What is nice to have? How will you manage changes eg will you work with a backlog that is prioritised by the customer at the begining of each sprint
• Budget: has a budget been allocated? If so, is it sufficient for the required scope? When will you know?
• Time: Is there a deadline? Or will it depend upon your planning?
• Team: you are the teamlead: will your team be 100% allocated to the job, or have they other things to do as well (support?). Make sure the impact on your schedule is clear. Make sure the priorities are clear.
• Will you have other people from outside your technical team on the 'project team' as well? What is your authority towards them?
• Will you only do development? Or will you do the roll-out as well? If not, who will? Who will write user manuals? Training materials? Who will do support afterwards? Who will train them? …
• Who will make the important decisions? The SteerCo? Do you have one? Your talking about new technology: who will make the desicion to use them or otherwise rely on some proven technology? Are there Go/No-go decisiopns to be made during the project? When are they scheduled?
• What about hardware? Who is reponsible for that?
• Do you need to procure something? Who is empowered to sign the order?
• Stakeholders: who is involved and needs to be kept informed? By whom? How will you report progress?
• New technology also involves risk: how will you handle this risk? Do you have a plan B? are there other risks that need to be handled to ensure "project development will work smoothly and didn't collapse at end movement"

All basic stuff, and I could go on and on. If everything is clear, so much the better. You may safely discard this post. But think it through. I won't promise a 'smooth' journey, but it will do for a 'smoother' one for sure ...