I want wrap up this blog by summarizing key “takeaways” that I gained from this project management course. My experience as a technical consultant helps me appreciate the value of project management, but my appreciation has grown measurably now that I have a broader understanding of the project management processes. In retrospect, I now better understand why I have seen so many projects fail, including my own. Unfortunately, there isn’t one single answer to prevent project failure. At the very least, project success is vastly improved if you follow the recommended process groups which utilize one or more of ten knowledge areas. Additionally, I now recognized how the establishment of a project management office adds significantly to the likelihood of project success.
Strategic planning: Strategic planning is a very high level process within an organization, and usually, I do not get involved with this process. However, I now understand how critical this aspect of a project can be, and should not be overlooked when assessing whether or not to go forward with a project. Be cautious if the project you are about start isn’t within the realm of an organization’s strategic plan; this could indicate tenuous corporate level support.
Initiating: Within the context of our class project, I gained a better appreciation for this task. In particular, I experienced the importance of working with project stakeholders early on and establishing expectations with a project charter. This process, I believe, created a working environment that allowed our team to transition smoothly between the remaining process groups.
Planning: I began the planning process with reservations after being selected the project manager for our group because I had little experience planning a project in a group setting. Additionally, project “war stories” from business students are much more negative than not. Quickly, I realized that the planning process does not have to be so burdensome when you allow the process to draw from diverse knowledge sets. By allowing each member to contribute from their experience, our project plan was completed much sooner than I expected. Additionally, the group strived to create a workload balance that made my job of assigning tasks easier than anticipated.
Soft skills: Though I didn’t encounter any negative issues with any team member, I had the opportunity to practice positive encouragement with my project team member. Instead of attempting to solve their issues or problems, I practice a technique of steering them towards a solution and fully accepting their choices even if I would have tried a different approach. By not dictating solutions for the project goals, I discovered that managing a project does not have to be troublesome. By acknowledging the value of their contributions, instead of dictating my perspective, the dynamic of the team developed in a positive manner that made fulfilling the project requirements easier and more enjoyable.
Best practices: As a computer programmer, I am keenly aware of the concept of best practices. However, the course project required that I broaden my definition of best practice, which was biased toward the technical. The OPM3 and other maturity models convinced me that my attitudes about best practices are too narrow, and they explain why some of my past projects executed poorly or failed altogether. The evolution pattern of standardize, measure, control, and continuously improve apply equally to processes and to your approach to processes. For me, it’s the continuously improve step that requires much more attention. From a general view point, this is much like the advise of not getting stuck in a rut. It’s easy to accept that change occurs, but we fall short in addressing the consequence of change because we flat out resist change. The take away I get from this best practice point is that continuous improvement on our approach to things is essential if we care to keep moving toward success.