Mapping out the organizational playfield is the key to effective project execution strategy
By Dev@Prudence
Projects exists within the ecosystem of the modern organization; a project is a living entity within an organization. Being aware of this ecosystem (a top down view) is essential in beginning to formulate an execution strategy.
Understanding this playfield boils down to:
- knowing how the organization works so that you can harness it to do project work
- knowing what available resources are there so you can utilize them
- knowing who is interested in the project so you can work and communicate with them
- knowing what the project is expected to achieve so that you can plan its work
The approach
To understand the playfield and be able to chart a course, you will need to:
- Understand the functional components of the organization
- Verify your understanding with management and internal leaders and seek their consensus.
- Document the project requirements and completion date
- Describe the scope
- Know the stakeholders
- Understand the work required to execute the project scope
- Map out the execution workflows.
The goal here is to understand how the organization describes its components. A component can be a group, team, unit or department or any other form of business entity. You simply pull this information without any judgement; much like a physician inquiring about the daily habits of a patient.
Start with the organization chart to understand the functional parts of the organization. Meet with internal managers, team leaders and key individuals within the organization to gather information on what the different teams do.
Describe each component.
3-Describe the inputs and where they come from.
4-Describe the outputs and where they go to.
5-Describe workflows or communication channels that occur in the course of producing the outputs.
6-Take note of any counter intuitive or unusual workflows or communication channels. You should closely examine and document a workflow if you observe anything resembling the following:
6.1-the workflow would only make sense to an informed insider. This means that it is not a simple input to output flow but there is a number of customized or ad-hoc steps as well.
This needs to be fully documented to make sure it is clear and agreeable to all internal stakeholders
6.2-The workflow does not fit neatly within the expected work of that team, unit or department.
This is related to processing inputs into outputs that is best done by another team. Simply put, it would be an area where a team performs a task that is traditionally or functionally best done by another.
For example, a team of IT specialists responsible for the daily maintenance of a data center but also do network design or server design work. Both designers and maintainers can be in the same group. The point is that the maintainer maintains and the designer designs. If you map out the responsibilities of both teams, you might end up with the below chart. Notice how altering designs is shared by both. This is a classic too-many-chefs-in-the-kitchen scenario; meaning that you cannot tell who is responsible for what.
Keep in mind that this is not necessarily an area of wrong doing. For example, the designer and maintainer can be the one and the same. It however needs to be examined to determine if the organization still wants work to be done in that way and that the person performing the function understand the work and is able to do it.
6.3-The workflow causes accountability dilution or spillage of work ownership to another team. This is an area that is related to:
Nonfunctioning feedback loops from one team to another where an input is determined to be insufficient; and therefore, it needs to be re-worked and resubmitted.
For example, a team of software developers sends a software build to a team of quality testers. The quality testers identify problems but then they are expected to alter code to fix those problems instead of returning the work back to the developers for correction and resubmittal. If you map the responsibility of both teams you might see something like the below. Notice how both teams are expected to fix code; which means that neither are fully responsible.
6.4-Incomplete inputs that carry the expectation that the team would bring them to completion to be able to use them to produce the desired outputs.
For example, the software developers and quality testers are both software savvy in the previous example. The developers provide the testers with incomplete work because they are busy and ask the testers to complete or “have a second look” at a few small portions before they start testing. Again, the responsibility mapping might look like the below.
6.5-Inputs that are expected from a different team.
For example, a publishing team wants to put a pdf user manual online and expects to receive this file from a technical team responsible for all product related documentations. The technical team sends the document to a technical writer to put it in the company approved format using the company theme colors and logo. The technical writer is expected to forward the pdf file to the publishing team instead of sending it back to the technical team.
If you map out the responsibilities, you might end up with something like the below chart. Who should the publishing team follow up with if they have feedback or questions to clarify? A publishing team member would likely see the technical writer as the source of the request clarifications. Is it his or her responsibly to guess that questions should go to the technical team? I know it is very obvious in this example, but the line will quickly become blurry as things get more complex and fast paced.
2-Verify your understanding with management and internal unit leaders and seek their consensus
This goes without saying. verify the information you receive from the team members with the managers of those teams and key stakeholders to verify your understanding. It is especially important that they also agree with what you listed in terms of inputs, outputs and what each organizational component does.
3-Document the project requirements and end date:
Some projects are initiated to address a specific list of requirements; some are intended to identify requirements. In other words, requirements are not always crystal clear from day 1.
Your goals here is to know what the list of things that the project attempts to achieve and is there a target date to achieve them
Requirements:
Finding project requirements and goals should not be too hard if a project is based on an agreement or a contract to achieve specific outcomes. This is often part of contractual language and agreements. It is a listing of what a client wants in a formalized way in relation to the situation or problem statement that the project is initiated to solve. You need to traverse the organization from end to end to find this list. Without it, you will not be able to know what needs to be achieved and your project will forever be in a constant state of flux in terms of scope.
If you can’t find a clear enough list of requirements, then you must work very closely with the key decision makers of the company to formulate this list and get their explicit approval and endorsement.
If the project is initiated to determine and produce a list of requirements for a future project or a program, then there are several techniques that you might employ. The best source on these tools and techniques is the section titled “Collect Requirements” of the Project Management Body of Knowledge (PMBOK), which is the de facto standard in managing projects and is authored by PMI.
Completion date:
Completion dates can either be imposed by the project sponsor, champion, client or the organization; or they can be proposed by the project team.
Contracts and such agreements will often list a completion date. This will be your absolute latest completion date. If you cannot find this date, then you must work closely with the key decision makers to find out if such a date has been communicated or promised in some form or fashion.
If no such date is determined or if the project team is expected to determine a completion date, then you should be able to propose one once you are able to determine work duration and develop a schedule after you are done identifying the required work and resources.
Contact Us
info@prudenceinc.com
1-850-PRUDENT