The word value is being used so often with stretched interpretations. From the insights shared in this post, I think the word value is so virtual and not always easy to define up-front. It is something that you admire when you see it and you cannot have prescription for. Of course we always target customer satisfaction and to meet the project constraints. However, we know that this objective can be done in different ways that produce different value. This value is related to and judged by the customer and development organization while it’s delivered by the project team.
In 2006 we were so proud of having our project management CMMI compliant. We had developed a defined process in great details with many templates. We were measuring performance quantitatively based on what we delivered against the up-front plan which was based on customer requirements. We were defining and addressing every potential risk, plan risk mitigation and put reserves for unforeseen risks. It worked! However, we continued to have the following symptoms.
Projects cannot survive without having the heroes. Those were the key people who inspired the rest of the team. The have tacit authority coming from their technical competency and alignment to the organization. They brought certain value to the organization that it needs and admires. Though this value was not known or even expected when they signed off to the project.
Measuring team performance was not meaningful. Many of team members were wizard developers who knew about technology much more than project managers and team leaders. It was not in our interest to tell them the expectation upfront. First because we did not know what we wanted other than getting the project accepted within budget and time. We made every effort to understand the requirements up-front for base-lining the plan. However, we knew unless this virtual concept named value is produced we will never succeed. What worked was when the team was motivated enough to produce this value, even if they delivered something different from base-line requirements. Surprise, that what the customer appreciated.
The developers were always expecting tasks assignment from the project manager who was monitoring and control planned effort, actual effort and deviation. He used to calculate the Earned Value was extensive use of project management tools and principles. The point is that the project manager can not assign meaningful tasks to the team as this would require high technical knowledge and understanding of many details. The project manager can understand the work flow of the development cycle and the required features. In addition understanding of build and configuration management functions. The greatest value admired by the project manager is the ability of the developer to deliver working software which normally included many details that can not be covered in any task assignment. However, we continued with tasks assignment rather give the freedom to the developer to decide what it takes to develop the features.
At the end, the product could work at the customer site through the effort of the so called heroes. Customer was asking “if I still need the same developer to get the project accepted, then what value I got from implementing these large processes”? This required value continued to be differentiators. Highly structured processes could not make people replaceable. It added documentation overheads and limited the free thoughts of the practitioners. We did not control the batch size so that we could have frequent releases with each have shorter time for testing.
Customers were hesitant to accept new releases
Customers were hesitant to accept new releases because of uncertainty associated with quality that could cause disruption in basic services. This in addition to extensive re-testing, which they did not have the resources to address. This has created the need to maintain multiple lines of code which highly increased the development cost. The value which we appreciated most was when we were able to put the new release at the customer site within certain threshold of business interruption. It required people with thorough understanding of: (i) the customer environment, (ii) limitation of existing release and (iii) possible risks from the new release. Again, this value is delivered by the project team.
Customer were annoyed by the long time it took to implement a feature
A key value that the customer admired during post-release was the ability of the development organization to provide a proper patch within a short duration. The priority became so high for patches which addressed critical business function. Still the on-site developers who are able to deliver a quick fix were providing highest business value to the customer.
Restricting deviation from the plan
The big plan up-front based on the base-line requirements derived the work of the project and even contract administration. The deviation from the plan was considered issue that needed to be resolved immediately. The cause of deviation is normally requirements change that could be raised by the customer or internally. This change represented certain high value which we could not anticipate from up-front. We tended to deprive the customer from this value in the sake of meeting the project constraints. Requirements change raised from the team were in most cases of higher value. These requirements could not be expressed by the customer. The customer could only discover the need of those requirements during acceptance test or live operation. This value was the highest from my opinion, though we missed. Losing this value significantly increased time for acceptance test, rework and high cost of maintenance.