Demo is the important for software projects. Project manager need to share the progress done at different stage to different stakeholders on regular frequency.
How you share your progress with the Key Stakeholders are the very important part of your communication plan and stakeholder management. Normally each project mentioned the milestone during creating a project charter. Each milestone ideally end up with either giving some deliverable to the client or showing him the progress made so far. We call this meeting as Demo normally.
Frequency of the demo depends and what methodology you are following. If you are following Scrum Agile demo happened during the each sprint. Ideally I give two demo in each sprint if sprint if of two week or more. First demo happen during start of second week. The main objective of this demo is not show the finished product to the product owner but to give them hint that what kind of output he can expect at the end of the sprint. He also make sure that there is no much deviation upfront. Usually, we share the Screens with the particular feature to give hint to the product owner about UI. If product owner is technical enough we share the database schema and api as well. This will give confidence to both product team and product owner that they doing right task and on the right way. We shield the team from any other changes suggested by the Product owner to focus only on the work items of the current team. I ensure the product owner that changes suggested by him will be taken care in next sprint and not the current one.
Second demo we do at the last day of the sprint. We call each stakeholders in this demo along with Product Owner and Scrum Master. We demonstrate the working feature created in the sprint to the product owner. We carefully note product owner’s feedback and comment.
In waterfall methodology, we do the demo at the end of milestone which is normally happen at the end of the each phase. In fix big project, it may happened at the end of different phase like Technical Design document review, Database Design review , API review, Completion of Visual Design, Completion of User Interfaces design, Completion of Navigation module, completion on reports design, completion of web console, completion of MVP features etc. However, project manager make sure that we keep showing demo to the client at regular interval normally weekly or biweekly.
As the demo is very important for the each stakeholders, there are lot of pressure on project manager to make it right.
Showing a demo is part of routing life of project manager. I am sure you would have observed as the project manager lot of challenges while preparing for the demo.
It is very common to see at the last moment that we encounter a critical bugs. We observed that navigation is not working properly. We wanted to show the web console to the client but it is not hosted as the developer is fixing some bugs till last time. While testing yourself you observed that report content is wrong. You are developing mobile and app you have observed spelling mistakes in UI.
We as project manager are facing this kind of challenges every week. Here some of the tips from my experience to deal with this kind of challenges.
1. Send a calendar invite to all the key stakeholder well in advance. I normally book a calendar at least one week before.
2. Prepare a demo script. Send the demo script to all the developers to give them hint that what you wanted to show in demo. Ask team to focus on those item first and nothing else.
3. Do the code freeze at least before two days of demo.
4. Create a separate branch for release. I normally asked to tag a code and ask the team to create a separate a branch namely release/rc5 from the develop or master branch.
5. Pull out a build from the release/rc5 branch and start testing.
6. Ask QA to test the Build RC5 and keep the ready list of known bugs.
7. If bugs are critical and show stopper ask the development team to do bug fixes in rc5 branch only.
8. Developer can continue their work in other feature branch.
9. Don’t ask team to fix bugs.
10. Before the demo I will share the list of known bugs along with the working features.
11. Will share the high level plan to resolve / fix all the kwon bugs as well.
12. Start the demo with the working feature of the product.
13. After that discuss the (impediments) known bugs along with dependencies, assumptions and risk. I will share and open RAID log with open items with key stakeholders. My idea here is that product owner and other stakeholder can help us remove this impediments.
14. Ask one person to take MOM during the demo other than one presenting a demo.
15. At the end of the demo ask person to speak out MOM in front of everybody.
16. Send the MOM to each stakeholder via email and keep it in Wiki for future reference.
17. End the meeting with discussion high level plan of the next week or demo.
Say for example I am preparing one Hybrid Mobil
Demonstration of the work done so far is very