Using Clarity in Key Management Areas

There are many ways in which driving toward clarity has an impact on project or program execution. We’ll discuss the key management areas to demonstrate how seeking clarity is utilized.

Planning

Let’s take the original problem statement that was the basis of our case study as an example for driving thought into plans. In the original iteration of the application on Windows, we wanted to chat with colleagues via a chat client but lacked the resources and permission for a centralized server. Taking the problem statement into consideration, solutions were explored to meet the requirement of operating without a central server. The chosen solution was a P2P network. Subsequently, high-level designs, low-level designs, and implementation phases were undertaken. Throughout these steps, various levels of ambiguity arose, necessitating clarification before progress could be made. While there were no stakeholders to convince or development team to guide, the need for clarity persisted, given the clear understanding of desired requirements but a lack of a precise roadmap for implementation. What was different then versus now was the scope and impact of ambiguity. In the beginning, the scope was limited to my colleagues on Windows machines, and there was no impact as it was simply a desired feature to have at the office. Therefore, the ambiguity was limited to how to accomplish the requirements. In the Mercury program that we are using in this course, the ambiguity stretches across both the requirements and solution, and there are stakeholders involved who are impacted by the work.

Now let’s expand this to the Mercury program that stands as the use case for this course. The problem statement is well understood, and the requirements are known at a high level: make a client for each operating system. Many open questions differ from platform to platform. For instance, mobile platforms need more clarity on the certification process for their respective app stores to form a project plan and a high-level design. Similarly, all platforms need details on how to initiate a broadcast call over TCP/IP in order to finish high-level designs. This also helps determine the level of generalization the network communication layer component can be designed to work with across the platforms.

As the high-level designs for the broadcast call come into focus, further changes to the program plan, and each project plan, may be needed. To add to the complexity, each application will be developed by a team in the company that specializes in their respective operating system and may have additional requirements unique to their operating system or the frameworks they use for development.

This iteration of the high-level design demonstrates how the planning cycles for the program and project can influence each other, and how driving clarity can feed right back into additional planning. Let’s take a closer look at the cyclical nature of planning and seeking clarity in the figure below: