Wednesday, 11 December 2013

Process Improvement is Self Improvement for Organizations

A very common term that is heard around in every business, across all industries, is “Process Improvement”. Senior management wants to focus on Process Improvement to increase the productivity and efficiency of already existing processes to perform better than their competitors. But are we doing enough to really improve those processes? If we are then, why some companies within the same industry performs better than others? Why not all the processes are efficient and productive as we want them to be? These are very thought provoking questions which are around for quite a sometime.

Let’s not consider two competing organizations instead let’s take a closer look inside an organization. In any organization there are different departments (Marketing, Software Development, Quality Assurance etc). Some departments have better processes in place that are highly productive and efficient while some departments unfortunately struggle to deploy new and improved processes. Why not all the departments have those productive and efficient processes in place? Why some department finds it easy to introduce new processes?

Solution to this problem lies within the new or improved process. The way in which the process is introduced has a big impact on the success of that process. Some departments are able to implement those highly productive and efficient processes because the manner in which those processes were introduced convinces the team members that the process will not only help the company to perform better but at the same time it’ll make their life easy and help them to grow professionally. Productive and efficient processes can be complex and sometimes confusing at first look. The very basic human nature is to avoid change and we are very good at it. We are happy doing stuff in 5 hours when that can be done in less time using a better process. But if we are able to communicate across board that all changes are not painful then introducing a new process can be a cake walk for us.

Process improvement doesn't always means to discard the already existing process and implement a completely new alien process.  So the question is, are there any well defined procedure to devise and introduce a more efficient and productive process? And the answer is No. The procedure for improving a process depends on number of different factors and among them the most critical factor is the acceptance of change by the team members. The focus should be on the VALUE that the improved process will bring to the team. If the team realizes the VALUE in the new/improved process then easier it becomes to change the already existing process.

But from where we will get these improved and efficient processes, In short how can we improve the processes that are already in place? Simple answer to this question is just by analysing the existing process. A simple way to analyse is to draw the existing process on a white board and then start marking the parts that are strong and need not/cannot be changed. In the end of this analysis you’ll get the parts of the process that are weak and can be changed for a better process. So now you have a very well defined area that you have to focus on. This is when you will start experimenting different options. An improved and efficient process is not created at once but it gets evolved over a period of time. All it takes is innovation and thinking out of the box. The important thing to remember here is never try to force the new/improved process onto the team but instead ask for their input and recommendation. You don’t want to end up looking in a different direction than your team. I have personally experienced a strong push back from one of my team when we were trying to introduce an improved QA process. In the start of that initiative whenever we conduct presentation/ work session the team looked completely disengaged. We were struggling to engage even a single member of the team. At that time, we realized that solution to this disengagement is to engage some team members on one-to-one basis understand what they think is a problem and show them the solution is in new process. This was the game changer for us, some of the team members started using the new process and they acknowledge that now they can work more efficiently. Seeing this rest of the team also started making efforts to adopt this new process. In a very short span of time we were able to engage the whole team and successfully introduced the new and improved process. The process that we introduced not only increased the productivity of team but also helped each individually to grow professionally.


Many organizations do not realize the value of a Process Improvement Analyst or consultant, who can audit the processes periodically and introduce changes whenever needed. With process improvement we cannot only achieve better productivity but also we can engage employees more effectively. So with process improvement techniques in place an organization can grow with a healthier work environment.  

Monday, 8 April 2013

Project Requirements: The only Truth



An ideal Project Requirement document defines all the deliverables in detail with the dependencies among them and there is no requirement change during the lifetime of a project but in real world there is no ideal project requirement document. Change request is an integral part of a project and I don't believe that there is any project completed without a change request and I am sure most of you will agree with me on this. But this doesn't imply that project requirement document is of no use and is just a formality. The main purpose of a requirement document is to record all the requirements initially and it needs to be updated with different change request that may surfaces during the project lifetime. 

If we record any requirement wrong or if there is any part which is left uncovered then the project will experience setbacks during the course of execution. So while writing down the project requirements one should always make sure that every part of the project is covered in the requirements and there is no ambiguity. It’s the project requirements which act as the basis for project plan and if we get all the requirements correct then only we'll have the correct project plan followed by timely project execution.

"It’s better to assume then to leave any requirement incomplete and ambiguous"

Let’s see how important is to make sure that we've have the correct and unambiguous requirements in case of a software project. Let’s assume a project xyz is near to its completion and testing phase of the project is going on. Testing is basically a process to make sure that behavior of the software is as per the requirements. What if the requirements collected in the very beginning of the project were ambiguous or incomplete then how a tester is going to make sure that the product that he/she is testing is what the customer asked for. The only way out is to ask the project sponsor one more time but it’s not that easy as it looks because the sponsor may now ask for something to which you never agreed upon but due to incomplete and ambiguous requirements you don't have any solid document that shows what were the initial requirements of the project and what you have agreed upon for delivering. I would conclude that without having a base lined project requirement document it's difficult to deliver a project on time and within budget.

So, one of the most important building block of a project is its requirement document.