For any of you that have ever read anything that I have posted in the past, you know that I always lean towards doing what makes sense rather than what is written in some book. Each organization, culture, team, and Project is different, so why assume that anything and everything is cookie-cutter? With all of the specific steps in many of the methodologies, to follow them to the letter would make Projects so process heavy that you would never get anything done. Sure, documentation and process are required to avoid total chaos, but isn’t our role as Project Managers primarily to communicate and coordinate what needs to be done, keeping everyone’s eyes on the end result? I contend that we all think outside of the methodological box, and champion what works for your unique Project environment.
Speaking of thinking out of the box, something that I have put in place in my organization are daily standup meetings with the entire Development group. Presently we have more than 10 Projects that are in some phase of development, and although most of the Developers are on separate initiatives, the sharing of status and issue related information has added great value. It offers the entire team time to share their knowledge not just on their piece of the puzzle, but to assist their team mates with problems or different perspectives on how to be the most efficient and effective. It keeps everyone involved with all initiatives currently being worked in some form in the department, and it helps us to better schedule movement between the development phases without having to be a slave to scheduling software. We are still small enough with a staff of about 20 to be able to keep this short and sweet, and we are able to keep everyone on the same page in a quick and efficient manner. With our culture and with the speed and volume of Projects going through the department, we really have no time to spare if we are going to keep all of the balls in the air. Also, with the continuous communication with the entire team, it has allowed us to decrease the need for hour long Development meetings which we used to have once a week. Now we only have those if we have major issues that we need the time to discuss behind closed doors.
Another practice that we have been using and are in the process of refining is somewhat of a hybrid Agile methodology for our software Projects. With the amount of initiatives that the organization has, we have had to create a Steering Committee which contains all C level executives, as well as institute Charter approval process. I work with the business unit in creating the Charter and while doing that I understand the business problem, then I take it back to the Developers and get a SWAG for the level of effort. Once the Charter is approved it is prioritized and scheduled, and once it starts the Developers start coding immediately off of their understanding of the Charter. As soon as they start coding, we in the PMO work with the business unit to define the further details required, and concurrently pass those to the developer, who works through us when there are questions. Now the nature of our Projects are medium size enhancements and changes to a very large highly customized ERP system, so this is working well. We aren’t really structuring stories and utilizing the SCRUM methodology, as we are doing more of a requirements document, but we are completing the documentation concurrent to the build as more of a “what we did” rather than a basis of “what we are going to do”. I think that this works well within the “barely sufficient” documentation structure that I am getting the department to follow, and it is attached to the Project at the end so there is some form of an audit trail as to what was done. I realize that in incredibly complex, long-term Projects this may not work, but in our department it is giving us the best of both worlds in terms of flexibility and just enough documentation to be able to understand five years down the road what we did in some semblance of detail.
So my lesson here is to try to think differently about what can fit your organization. We don’t always have to deal with specified structures the way they are written, we are hired because we have brains, so let’s find new ways to get better results by customizing what we know to our unique situations.
Margaret de Haan, MBA, PMP, CSM