Friday, January 13, 2017

Progress and Status Meeting Templates


Development/Release Meeting

Run this meeting by release.  If there is only one release, check for the current release.
After code complete, start with QA to know where we are. 
  • Any blocking issue (hardware, software, human resource) for testing 
  • Test case - completion.  What area are tested and what are remaining?
  • # of bugs to be tested/verified? Pipeline for QA
  • Satisfactions - Pass Rate? New issues? Regression?
  • Check Exit Criteria
  • Whether we can get into release candidate phase
The goal to ensure that the product can be released with quality.

Before code complete, start with DEV by area
  • Design sign-off
  • Coding - what have been done, estimate the remaining work
  • Any functional design clarification? - many activities within a day without waiting for the regular meeting
The goal is for product to be completed and ready for testing

Development Planning Meeting

Scoping decision for a release or for a sprint.
Use the backlog list as the input
  • What are the main theme for each release?
  • What are the criteria for adding a feature in
  • What is the target date?
  • Who are the main customers
  • Scope - Time - Resource Triangle.

Customer / Support

Run this by customers and by tickets
Typically we should have a customer advocate for critical customers.
Customer Implementation Phases:
  • Design questions about how to do XXX
  • Test - how to migrate from Test to Dev, share the knowledge about methodologies, and experiences, what work and what does not.  What are the best practices?
  • UAT - the deploying company will handle this but share the user feedback
Customer Go Live support - on the D day
After go live, any customer/end user issues

What are the customer bugs logged by or for the customer?  What are the status?
  • Can we reproduce?
  • Have we committed?  
  • For the committed bugs, have we fixed?  Which release the fix will be available?

Presales

Run the meeting by customers/prospect.
Build the Demo env and build demos (for each)
  • What are the scenarios the customer is looking for
  • What are the gaps of the product and what we will do for them?
  • Future Roadmap? Scheduled Enhancement?  Any workaround?
  • Success or Failure?  What lesson learned ?
Logistic - When? Who? Travel required? 



Saturday, December 24, 2016

If you don’t change, you shall be removed from the competition.

A good lesson from Nokia.

Nokia CEO ended his speech saying this “we didn’t do anything wrong, but somehow, we lost”. 

Those who refuse to learn & improve, will definitely one day become redundant & not relevant to the industry. They will learn the lesson in a hard & expensive way.

Wednesday, December 7, 2016

Eat your own dog food

In software business, this means that you are using the software you developed like customers, so you can have the experiences as the users and can better understand their requirements and issues.

There is a good and a bad impact of this policy.

The key controversy is about which version of the software.  Following the thought, one may argue that the latest software should be always applied internally before shipping and sharing with customers.  The problems are

Thursday, October 27, 2016

Release Notes

When we ship a software package, we should ship the documentation alone with the software.  Every time when a new release is available, a release note should be available as well.

If it is a Beta release, there should still be a Beta release note.

Friday, October 7, 2016

Software and service companies should work 24x7 like hospital

Actually this is true.  The expectation is high and competition is high.  Nowadays, especially SaaS based service companies, you are expecting the service is never stopped. Here is how we can accomplish: