|
The majority of articles on project management training are targeted toward students already motivated to learn project management. Selling project management to a project management-hungry audience is an easy sell. A greater challenge is motivating a team of technical gurus to embrace project management processes to help deliver their projects. This article will describe one success story of how a PMO successfully implemented PM training in a technology-heavy and process-light organization.
A few years ago, I joined an organization that needed significant help delivering infrastructure projects. The organization was comprised of brilliant IT engineers and solution developers that could talk ad nauseam about the delicate intricacies of VMware server virtualization and the latest dot release of Websphere in a Linux environment. However, the organization struggled with scope creep, schedule overruns and sporadic project start-up.
The organization implemented a PMO to provide project management support and training to the team of technical leads. Teaching the techies was a challenge since technical innovation and project management processes don't always peacefully co-exist. The PMO focused on the following content, training approaches and reinforcement techniques to help the organization adopt PM processes with technical infrastructure work.
Content
Since the target audience wasn't motivated to learn about project management and had little if any PM process background, the PMO's approach focused on the high-level project management process lifecycle and the core documents needed to successfully deliver the project. The PMO recognized approaching the organization with the IEEE 12207 standard or the PMBOK would overwhelm the audience. The organization was already resisting the company's SDLC, and additional processes were perceived as wasted overhead.
A 30-minute presentation was developed to align the company's SDLC with project management processes. The presentation focused on the fundamental initiate, plan, execute, control and close phases of the project lifecycle. Within each phase, the presentation highlighted the critical documents within each phase. Table 1 includes the key documents for the organization:
| Phase |
Document |
| Initiate |
Project Charter |
| Plan |
Project Schedule |
| Execute |
System Requirements document
Technical Architecture document
Test Cases
|
| Control |
Issue/Risk/Change Request Log
Status Report
|
| Close |
Lessons Learned |
CMM specialists and PMBOK enthusiasts would criticize the list as being too short; however, the PMO needed to start with PM basics in order to gain adoption. With each document, the PMO explained the importance of the document and how it supported the process.
The project charter was a summary of the project's scope and context. It was limited to two pages and was augmented as needed. The project schedule was introduced to identify key dates for delivery rather than weekly "best guesses" when technical teams thought the project would be completed. The technical team liked the system requirements and technical architecture document since it explained what was needed for the project.
The concept of test cases was new to the team members. Structured testing was non-existent; however, the team eventually migrated to Excel to track test cases and their results. An integrated issue, risk and change request document was implemented to identify critical issues, risk and scope changes. The team liked the idea of change control since it controlled the gold platting and the incremental scope creep.
The greater challenge was collecting a status report document on a periodic basis. The PMO implemented a Web-based project tracking tool for technical teams to update their project status. By provided the tools without the bureaucracy, the process was adopted easier. Finally, at the end of the project, documenting the lessons learned provided a reminder of what worked well and what failed for future reuse.
Training Approach
Obviously, the adoption of PM processes didn't happen automatically. The PMO spent 18 months working with the technical teams to implement process and eventually realize the benefits of project management. The PMO adopted the following approaches:
1. PM Staffing
2. Lunch and Learns
3. Team Presentations
4. 1:1 Coaching and PM Mentoring
Initially, the PMO staffed knowledgeable project managers to manage the technical projects and execute the PM processes. By integrating PMs within the server and infrastructure management environment, the technical teams were able to leverage the PM's knowledge and learn through observation. As knowledge transfer occurred, PMs were reallocated to high-priority projects and the technical resources were knowledgeable enough to play the PM role on smaller scoped projects.
The PMO also hosted lunch-and-learn sessions that were sporadically attended. However, the PM concept was being adopted in other departments within the infrastructure division. Awareness was raised and the technical teams recognized they should learn a little bit about the subject. In order to further integrate process with technical development, the PMO presented at various staff meetings on how PM processes actually benefit projects. The PMO also partnered PMs with team supervisors and team leads to coach and mentor on PM processes.
Reinforcement
Training and awareness are only effective if it is reinforced. The department experienced significant organizational change as the PM processes were implemented. The PMO managed the portfolio and prioritization of projects with senior management. If team leads wanted resource for a project, they needed to follow the project initiation process and provide a project charter.
If internal application teams wanted Web hosting space or wanted to implement a new piece of technology, the requestor had to follow the PMO's engineering review process and provide a technical architecture document. The key to implementing project management processes was funneling the work requests through the PMO and expecting requestors to provide the PM documents.
The required documentation was tailored for efficiency and didn't waste reams of paper to convey a project's scope and requirements. A clear indicator of success was when the department manager directed other IT directors to follow the request process to initiate new projects. The process worked, and it was refreshing knowing senior management supported the processes instead of defaulting the usual "just get it done" approach. The visibility and urgency to respond quickly still existed, but the PMO had visibility to the request and could respond accordingly.
Teaching PM processes to techies can be a daunting task; however, by scaling the scope, customizing the content and providing the appropriate knowledge transfer, it can be accomplished. Senior leadership still needs to sponsor the effort and set expectations for processes to be followed. The key to implementing project management within a technical organization was making the project management processes nimble enough that they delivered value without the non-value added overhead.
Now if I could only get the techies to understand earned value...
|
