Efficiency in software process and delivery is achieved in large part through our 'qualitative' understanding and construction of the plan. This is in stark contrast with the common propensity to focus on the mechanics of delivery which makes everyone involved acutely aware of the project milestones, processes and tasks but takes the focus away from the strategy behind the plan, risk assessments, mitigating factors and the navigational choreography needed to achieve 'success'.
Over the past few decades, there have been at least three generations of 'process wars' as the software processes, methodologies and technologies evolved to meet the accelerating needs of the technology and society. With each one of these paradigms evolved a generation of tools and infrastructure--all supporting optimizations in the development and delivery processes.
There is no doubt that these evolving processes and tools contribute towards making a development team efficient in its delivery--but--BUT--it's not enough.
At all levels, whether an engineering executive, a project or development manager or an engineer--everyone needs to have a strong (relevant to their individual roles) understanding of the tasks, plan and project at hand. None of the tools, technologies or platforms that are available on the market today support or enforce this level of analysis or understanding. This in turn allows all key participants in the software delivery to resort to regulating the mechanics of the delivery--in other words--becoming and acting like robots.
Robots cannot deliver software; humans are having enough trouble with it.
Given that software development is a precarious balance of 'art' and 'science', primary focus on delivery mechanics and tools increases delivery predictability BUT also an overall failure of expectations in the end. If we have not understood the overall strategy, plan or risks, I assert that we cannot succeed in delivery (i.e. satisfy our customers) by focusing only on the mechanics of execution, no matter how precise we are in meeting the delivery expectations and 'defined' goals.
Sanjiva, Orinda, CA, Nov 18, 2005
While writing up a project plan last night, this blog popped up in my head all of a sudden. So I decided to be opinionated again ...
I have seen many software engineering projects not going as smoothly as expected due to communication gaps among departments. In particular, a commonly seen gap is the one in between product functionality requirements and the engineering specifications. Department managers spend most of their time in back-to-back meetings just to cover various aspects of projects at hand. Such exhaustive exercise is supposed to synchronize mutual expectations among different functional groups. Yet, much of the outcome from these endless meetings often fades away as quickly as the sound wave in the conference rooms and historical email in inboxes.
With an interactive system containing the essence of a project, communications no longer have to filter through department managers to their own staff. Essentially, this system is a centralized repository keeping the essential elements of a project, at both strategic and tactic levels, up to date at all time and first-handed with minimal "distortion" to all participants across departments. It also serves as a version control system of the entire project. More importantly, it is the reflection of expectations in synchronicity.
Core strength of such a system lies in the intelligence of how various pieces of information are associated with different components of a project and merged into the flow of the process. In addition, how they get propagated accordingly to individual participants of different roles also decidedly determines the effectiveness of the system.
Posted by: Leo | November 27, 2005 at 04:33 PM
"Robots cannot deliver software; humans are having enough trouble with it."
Right. The impulse to routinize work arises out of people's desire to get paid for NOT thinking.
Posted by: Doug | December 01, 2005 at 05:08 PM