Projects are neither good nor bad: they’re neutral. They succeed or fail because of what team members do to them, the skills each team member brings to a project effect its ultimate success. Most executives understand this and that is why they spend money on training because raising the skill level of team members increases the odds that projects will succeed more often. But, even a highly skilled project team will struggle if the project environment they work in is not conducive to project work.
What is a project environment? In a nut shell, the environment is made up of three elements: the process, tools and culture of an organization. It can help or hinder a project team’s ability to produce desired results; and, more importantly, it is often not addressed by executives when trying to raise an organization’s proficiency at delivering project results.
Let’s examine each of these elements in more detail. An organization’s processes describe how to manage a project, define business requirements, produce deliverables, and test and implement a final product, to name a few. Processes are the means by which an organization obtains consistency and maintains governance over how work gets accomplished. An organization’s tools assist in carrying out the processes through automation. They bring about efficiency and enhance the skills of the team members. An organization’s culture is much less tangible, yet it has a great deal more influence over any given project team. It drives individual behavior through observed unwritten laws.
So what happens when companies only invest in training for their employees and don’t address their project environment? The project results are definitely improved, but executives tend to become disappointed with the degree of change. Systemation has helped numerous companies with their project environment and all of them have followed the same path‑regardless of the advice we gave them. We now believe that even though this path may not be the most efficient way, it may be the only path to obtaining the desired outcome. Let me give you an example.
Steve was our project sponsor and hired us to help him with his organization’s project environment. He wanted us to integrate Microsoft Project’s Enterprise Server after we had trained nearly half his 500 project managers on general project management skills. We advised Steve to first focus on the project management processes but he believed he did not need to do so because his PM’s would use the processes we taught in class. After installing the tool it mostly sat idle except for the few who used it in various non-conventional ways.
Steve soon realized he did need to develop his own processes so he put a committee together and they developed a full suite of project management processes. The committee did so in detail and even ensured the processes integrated well with Microsoft Project. We advised him that the processes were too controlling and did not allow for the right level of autonomy needed to function in a project based organization. We also thought they needed to be more oriented towards results than actions. As expected, the project managers became frustrated with the processes because they were too controlling and did not have the flexibility to meet a wide variety of situations.
Steve saw that the process reflected a culture that was not consistent with how project work got done at his organization. He ended up spending several months helping his management team change the way they managed their employees. The management team learned to take a more hands off approach and use project results and gate points to evaluate and take corrective action. They then revised the project management processes to integrate better with the new culture they had established.
Obviously from this story you can tell that it would have been quicker for Steve to change his organization’s culture first; then create the right type of processes; and then select and integrate the right tools. That old saying of “you don’t know what you don’t know” applies here. I don’t think Steve could have gotten to the end result any other way.
Steve ultimately realized a much greater degree of project success throughout his organization but, he had to put in the effort and time to make it a reality. Relying totally on training will not get the project results you are looking for. You have to address the project environment too.