According to PMBOK, “The project benefits management plan is the document that describes how and when the benefits of the project will be delivered, and describes the mechanisms that should be in place to measure those benefits. A project benefit is defined as an outcome of actions, behaviors, products, services, or results that provide value to the sponsoring organization as well as to the project’s intended beneficiaries”[1].

This document is a living document and according to me, its life-cycle starts way before any business plan is laid out. Information exists for this but maybe not in a centralized place. Many factors such as business execution environment changes (evolution, devolution or revolution) and/or strategy, management and economy changes are the ones which trigger activities that generate a probably viable business sustenance/execution plan.

Project management has been very much talked about and PMBOK is an excellent resource to get all the relevant information. I think people everywhere in public & private life do understand the value of project management. Simple tasks in everyday life (eg: go for an offsite meeting on Friday evening ;)) are looked upon as projects by parents. Everybody involved (husband, wife & children in this case) needs to be on the same page when it comes to execution.

Before I start writing on Digitization/Digitalization, maybe we should spend a little time in exploring the alternative “Analogization”! Now I have made up that word and probably the more appropriate word might be “Materialization”[1][2] but comparing the past/existing with the upcoming/future will give a perspective and provide a context for my thoughts.

As human beings, we have been generating information right from the start of our existence and materializing it as physical objects. These physical objects were hard to manage, cross-reference, study & derive from. With the new age technologies, we are now at a stage where we can convert all the physical form of materializing information into digital bits & bytes that can be read, stored, coded and decoded by computers (Digitization).

I recently got a Netgear R6220 router, an AC1200 dual-band router with very impressive specs. It was awarded the best router in 2016 and now in 2019, I still think it is a very good router. It has a 2 core Mediatek MT7621 (MIPS) processor with 128 MB RAM & 128 MB ROM i.e. ample space with some good processing power. Below you can see the impressive specs. BTW: I got this for almost 15 USD which was a steal!

My thoughts on why and how metrics/measurements of ongoing tasks should be done.

I will start with the practice. The problems we are trying to tackle is:

1. How to make our team believe in their own estimations?
2. What is our cycle time?
3. How do we project the probability of fulfilling the sprint goals?
4. How do we track the state of the task?
5. How do we ensure continuous development of processes?

For the last 3 questions, I suggest referring to the self-explaining Cumulative Flow Diagrams (http://www.slideshare.net/yyeret/explaining-cumulative-flow-diagrams-cfd). Martin Alaimo writes on measuring sprint progress in the Scrumalliance community blogs (https://www.scrumalliance.org/community/articles/2011/may/measuring-sprint-progress). Essential Scrum: A practical guide to the Most Popular Agile Process by Kenneth S. Rubin (p.357-359) defines how task metrics can be visualized (though in a table formation) (https://books.google.se/books?id=3vGEcOfCkdwC&pg=PA357&lpg=PA357&dq=visualize+tasks+in+scrum+boards&source=bl&ots=-BBbkkfr_l&sig=KqO_9xWDIEM3hVqe-9QSi0IQKQQ&hl=en&sa=X&ved=0ahUKEwjZk9ztxurKAhWFs3IKHYioBLE4FBDoAQg9MAU#v=onepage&q=visualize%20tasks%20in%20scrum%20boards&f=false). An electronic task board showing the progress (https://www.targetprocess.com/content/uploads/2013/11/lists-sketch-for-Targetprocess-3.png). A detailed article by MSFT on Task board (of course tailored towards VS Team edition usage but has lots of details) (https://msdn.microsoft.com/en-us/library/vs/alm/work/scrum/task-board). Another article (https://blog.taiga.io/q-id-like-to-measure-the-sprint-progress-through-closed-tasks.html) very good on why sprint progress should be monitored regularly and not at the end of the sprint.

Year 2014 was very interesting for me both professionally and personally. It had its own ups and downs. Today I want to retrospect on 2014 and important things that happened around me!

2014 started with an exciting CES in LA where demos with M7450 and SLSI 44xx were shown. Proud to mention that I had been very heavily involved with the bridge implementation on SLSI 44xx and M7450. And in Feb 2014, I was in Mobile World Congress (MWC) in Barcelona with Ericsson modems business showing 5 different demos ranging from global device to carrier aggregation (CA) to CAT4 DL speeds on real live Ericsson back bones. Proud to say again that I was the one who coded all the demos in various technologies.

Many of my friends using Linux have serious problems with switching screens, screen resolutions, connecting to projectors, etc. and all of them end up wasting humongous amount of time doing stuff like that. And after banging their heads for 30 minutes they curse Linux and all and put up a request for another meeting! Anyways, below is the code to get screen toggling and switching screens easily done. Of course one needs to modify to suite their own use-cases but I guess the script itself will suffice most people.

Now WTH is Blind Debugging? Well, thats what I have been doing for the past 2 weeks everyday for 14-16 hours a day! I am working on a new top secret project(!) where there is a lot of intercommunication happening between 2 systems. One of them is a master and one is a slave. The intercommunication happens with a list of complicated protocols. Now comes the bad part. I don’t have source code access to either of the systems and my task is to get some things working in both the systems!