There can be confusion over the differences between an operational process, a project, and a program. In some cases this confusion is on purpose. As a Project Management consultant, I was brought in to help manage the work on one or more projects. As I dug into it, I found that some of the work was not really a project. Projects have a start, an end, deliverables, and are created to handle a specific business need. Projects can have multiple phases, projects can be used to improve and expand, and they can transition into a deployed using an operational process.
Handling multiple projects can lead to the work creeping upward into the area of Program Management. This is where the view shifts from getting the work on a project done to looking at the business strategy and how all the projects fit. The focus shifts into prioritization between projects, resource allocation on a larger scale, risk management that focuses on the impacts to the business, and the processes around starting, tracking, reporting, killing, and completing projects.
An operational process is an on-going set of tasks and most are focused on the day to day work supporting the organization. Work targeted at improving these fall into the continuous process improvement area. Because a project can be used to implement a significant change to one of these processes, there can be confusion. Some of that confusion contributes to the resistance to killing a project. It also is a factor in the reluctance to declare a project finished. This desire to call everything a project is especially strong if the business groups know that a process is not working well but do not know how to fix it. A transition from a project that is going well into a poorly run process is another reason that the business would want the project to continue.
The skill sets and expertise that makes you good at each of these is a little different. It is not difficult for the same person to be good at all three. The critical thing is to know when the work has shifted from one to another. On a recent consulting assignment, I set up the Program Management structure, creating forms, processes, and presentation formats. This provided a standardized method to request to start a project, track and report on-going projects, and prioritize the projects. On some of the projects, I was also the Project Manager, working to collect requirements, define and assign tasks, determine deliverables, etc.
I had set up and improved operational processes before, so I knew I had the expertise. But I was brought in as the Project Manager. I resisted attempts to get me to take over someone else’s area and fix the operational processes, too. I had continuous discussions explaining how a project and process are different. There were some attempts to disguise a broken process as a project. After some work and digging, I would unmask these impostors.
Setting up the program and project parts are important and a significant amount of work. The reality is that most, if not all, projects end up sitting on top of operational processes. The project initiation form collected the assumptions, constraints, and the fact that changing the processes were out of scope. The risk management documented these processes as risks items. None of that saved us. Projects became derailed, delayed, and negatively impacted because they were sitting on top of a bad process.
Next time, I will get into the mud and help shore up the process foundation. This will not be glamorous. It will also require skillfully navigating between two sharp and jagged rocks. One side is educating management that processes need repair. The other is avoiding having the people working on those processes see my work as a threat.
Technorati tags: project management; software;program management;
Saturday, June 24, 2006
Friday, March 24, 2006
Bamboo and Project Management
No, this is not about some Project Management software from China. This is about using a flexible, light weight structure to support the Project Management efforts. There is a large amount of confusing about Project Management. My approach has been to use it to apply structure and form. While traveling through Asia, I saw people using bamboo as scaffolding for construction work on buildings. Most people see Project Management structure modeled on traditional Western scaffolding, heavy, strong, durable, and complex. My approach has been more aligned with the properties of bamboo, light weight, flexible, and simple to use. That is not to say that it is flimsy or fragile. As with the bamboo scaffold, your Project Management structure gains strength by adding more where you need it.
Ok, it is a great metaphor, but how do we turn that into action? The obvious but often overlooked starting point is to keep it simple. People, especially senior mangers, need to see the message with minimal explanation. While a number have are familiar with Gantt charts and other views from project software, it is not the right answer for everyone. So, I start with a pretty picture on a MS PowerPoint slide. The picture should show everyone, at-a-glance, what projects are underway, top level time based depiction of each phase in each project, and a simple stoplight color scheme to illustrate the project status. Based on that one slide, we have a great deal of information to talk about resources, risks, project portfolio management, and candidates for extra resources or termination.
Of course, a large amount of detail and data needs to be collected and analyzed to create that simple picture. I do not think that this task should mandate using any specific tool. Instead, you should be free to use or not to use any tool or software that makes collecting and updating the information easy. I have worked at places where they had a full time person whose job was to update a MS Project schedule each day. Projects that have short durations or are in a high state of change need a more light weight and flexible approach.
I found that giving the tasks owners a simple template in MS Word or MS Excel provides enough structure and easily gets me the information I need. But there is one hole in this system that still needs to be plugged, tracking resources for each task. If you are careful, you can use MS Project to map it out. And this can serve as the building block when you need to show an “official” project Gantt chart.
Keeping the Project Management structure flexible and light weight, like bamboo, provides the tools to support the work without diverting a large amount of work into changing the scaffolding when the project changes. This approach is even more useful when you are introducing Project Management into an organization.
Technorati tags: project management; software;
Ok, it is a great metaphor, but how do we turn that into action? The obvious but often overlooked starting point is to keep it simple. People, especially senior mangers, need to see the message with minimal explanation. While a number have are familiar with Gantt charts and other views from project software, it is not the right answer for everyone. So, I start with a pretty picture on a MS PowerPoint slide. The picture should show everyone, at-a-glance, what projects are underway, top level time based depiction of each phase in each project, and a simple stoplight color scheme to illustrate the project status. Based on that one slide, we have a great deal of information to talk about resources, risks, project portfolio management, and candidates for extra resources or termination.
Of course, a large amount of detail and data needs to be collected and analyzed to create that simple picture. I do not think that this task should mandate using any specific tool. Instead, you should be free to use or not to use any tool or software that makes collecting and updating the information easy. I have worked at places where they had a full time person whose job was to update a MS Project schedule each day. Projects that have short durations or are in a high state of change need a more light weight and flexible approach.
I found that giving the tasks owners a simple template in MS Word or MS Excel provides enough structure and easily gets me the information I need. But there is one hole in this system that still needs to be plugged, tracking resources for each task. If you are careful, you can use MS Project to map it out. And this can serve as the building block when you need to show an “official” project Gantt chart.
Keeping the Project Management structure flexible and light weight, like bamboo, provides the tools to support the work without diverting a large amount of work into changing the scaffolding when the project changes. This approach is even more useful when you are introducing Project Management into an organization.
Technorati tags: project management; software;
Tuesday, January 31, 2006
Software Project Management – shifting from a directed to a collaborative model
When software development started, they used the existing project management techniques. Those tools and techniques worked well for people constructing buildings, but they did not provide good tools for managing software projects. Using the standard water fall method, each step was completed, leading in a straight line to project completion. I know that this is a simple view. Some of the steps had overlaps so that the proceeding step could start before you finished the previous step. But, in general, the assumption was that all the requirements could be started at the beginning and that they changed slowly. People had thousands of years of experience interacting with and creating buildings. Not only is software a relatively new area, it is rapidly changing.
Dr. Barry Boehm published a new approach, the Spiral Software Development model, in 1988. This was a way to address the IKIWISI syndrome ("I can't tell you, but I'll know it when I see it”). In recent years, a number of new techniques have been created to address the problem of the customer not being able to give you all the requirements since they do not know all the requirements at the start of the project. Most of the techniques try to address this problem by developing what you know as fast as you can, so that you can present it to the customer. As the customer sees more of the software “functioning”, they can do a better job of clarifying the requirements. This happened in the earlier methods but was seen as “scope creep”. Due to this new information and requirements appearing late in the development, it was very costly to add the changes. That created an elaborate change management system which tried to reduce the number of changes.
The biggest change that has occurred from using the new methods is that the relationship between the project team and the customer has shifted. Instead of the project team being directed by the customer, we have shifted to a collaboration model where the project team and the customer work together. This is an important and critical change if we want to develop complex software projects that will be usable and support the business goals. The software project manager’s work shifted from coloring in triangles on a chart and driving work to fit to the plan, to that of a navigator.
As the project navigator, the job is to scan the horizon for changes, work with the customer to determine if the change impacts their goals, and then using that information to keep the project team on course. Continuous collaboration is now the key skill of the software project manager. The shift in the role of the customer means that they need to be more involved and need to work with the development team to surface decision points, eliminate undocumented programmer assumptions, and understand the trade-offs.
The current methodologies and techniques all work well in specific situations. Selecting the one best one will depend on the business culture and processes, the training and flexibility of the team members, and whether the requirements will change over the course of development. No matter which one you use, the software project manager has to keep the customer engaged and involved.
Technorati tags: project management; software;
Dr. Barry Boehm published a new approach, the Spiral Software Development model, in 1988. This was a way to address the IKIWISI syndrome ("I can't tell you, but I'll know it when I see it”). In recent years, a number of new techniques have been created to address the problem of the customer not being able to give you all the requirements since they do not know all the requirements at the start of the project. Most of the techniques try to address this problem by developing what you know as fast as you can, so that you can present it to the customer. As the customer sees more of the software “functioning”, they can do a better job of clarifying the requirements. This happened in the earlier methods but was seen as “scope creep”. Due to this new information and requirements appearing late in the development, it was very costly to add the changes. That created an elaborate change management system which tried to reduce the number of changes.
The biggest change that has occurred from using the new methods is that the relationship between the project team and the customer has shifted. Instead of the project team being directed by the customer, we have shifted to a collaboration model where the project team and the customer work together. This is an important and critical change if we want to develop complex software projects that will be usable and support the business goals. The software project manager’s work shifted from coloring in triangles on a chart and driving work to fit to the plan, to that of a navigator.
As the project navigator, the job is to scan the horizon for changes, work with the customer to determine if the change impacts their goals, and then using that information to keep the project team on course. Continuous collaboration is now the key skill of the software project manager. The shift in the role of the customer means that they need to be more involved and need to work with the development team to surface decision points, eliminate undocumented programmer assumptions, and understand the trade-offs.
The current methodologies and techniques all work well in specific situations. Selecting the one best one will depend on the business culture and processes, the training and flexibility of the team members, and whether the requirements will change over the course of development. No matter which one you use, the software project manager has to keep the customer engaged and involved.
Technorati tags: project management; software;
Subscribe to:
Posts (Atom)
