Project Practitioners > Project Management, Methodologies, and Organizational Maturity

Project Management, Methodologies, and Organizational Maturity

By Margaret de Haan

In my last few positions, I have spent time setting up the Project Management discipline in the organization, and ultimately creating a "PMO" in each .  Now, whether you would agree
with me or not, I believe that PMO's are created and customized to meet the organization needs at the time that the department and processes are set up, in other words, there are no "cookie cutter" implementations.  Looking at each Project Management Office, or function (or even the Methodology that was implemented) was directly linked to what that organization's culture could handle, and what could be implemented successfully.  In each company, what that ended up looking like was vastly different, not just based on their type of business and product, but what the associates in the company understood and were comfortable with.  So do I think that there is "one best way"?  My thoughts are: Yes and No.

Let’s face it, Six Sigma, Scrum and Waterfall as methodologies all have merit depending on what type of product you are creating, how fast the cycle is, the degree of variability in the market, and so on.  I prefer the flexibility and feedback loops that exist in Scrum development, but I realized early on that in my current organization that wouldn’t work with the culture and attitudes (as well as with some of the training) that many of the managers had gone through.  If what everyone is hearing is more along the lines of a Waterfall message (deadlines are hard, you have to know what you are creating in specific detail before you start Development) then trying to implement anything that is in conflict with that message will not only cause confusion, but will not be followed and therefore will fail.  So in my current position, I decided to go back to basics and just start at the beginning.  By the end of the year I will be rolling out and providing training on the Standard (Software) Development Lifecycle.

Yeah, I know, there are arguments that the SDLC isn’t a methodology (it’s a Life Cycle, I know, it’s in the name after all) but when you need to start at the beginning, I figure that the first logical step is to introduce the organization to how IT’s process works, then we might be able to move more towards a Project methodology.  In tandem, I will be rolling out an introduction to roles and
responsibilities on a Project, as well as the Help Desk and Project request and approval process.  Definitely the beginning of the spectrum, but I am always the first to discuss and try to get the organization sold on the concept of foundational knowledge before details, after all, you can’t be worried about where the windows will be until you at least know where and how big the walls are, right?

So, let’s get back to organizational maturity.  Months ago, a few other Managers in and around IT suggested jumping right into an Agile/Scrum process which made me panic!  My thoughts at the time were around the concept of continuing to allow change in an environment that is not practiced at knowing and communicating what they want.  I was asked by someone whether or not we did iterative Development in my organization, and I had to tell them that we did, but “it’s not on purpose”.  Yup, it’s because of the “that’s not what I meant” and “Oh, we didn’t think about how that would impact “X””, so I felt that going “Agile” wouldn’t move the associates closer to “speaking Project” and that it would allow for continued requirements churn.  On the other hand, allowing business owners flexibility (which I believe we do in balancing the triple constraint) it could seem to outsiders that implementing Agile would fit right in with the current organization. That might be true, but in my opinion with most of the culture thinking that IT is a service organization and not a partner in the business, would mean that a Project would never end.  We are currently running very resource thin in IT, and so the business really has to sell their Projects to the Steering Committee to get them prioritized and scheduled.  That environment could drive members of the business to try to keep Projects open indefinitely, and keep creeping the Scope into required functionality for other needs that were not defined in the Charter, and result in “project blending”.  Sure, that is what the Scope document is for, but when you had an IT organization three years ago that was nothing more than break/fix shop, and the Developers did what they were told how they were told to do it, the culture isn’t ready to hear the word “No”, especially from IT.

Regarding the “one best way, Yes/No” comment, I personally love Scrum as the basis for a flexible methodology that I think works incredibly well for Software Development. With the wisdom that has been gained in the last 20 years around the need for flexibility, speed and staged functionality rollouts, that in software the “Waterfall Way” has proven antiquated when you are in a competitive environment and when the Project is really large.  Requirements change over time and really how reasonable is it to expect the business owners to know everything that they will need in a year or two years from now? OK, this methodology and critical path management works well for building construction, but not necessarily when you are developing software.  So I like Scrum.  A LOT.  But, is Scrum the BEST fit everywhere, all the time?  No.  The organization has to be mature enough to handle the flexibility without running amok.  Flexibility does not equal a lack of discipline, on the contrary, I believe to manage flexibility properly requires a LOT of discipline.

So my advice is when developing a Project Management structure and process, realize that the success and failure isn’t just about what you think, but what the business thinks and will be most willing to implement and adhere to.  To be successful, everyone has to be willing to follow the rules, and if they fit in with the maturity and culture of the organization at the time of rollout, there is a better chance of success.  I would rather be trying to put a square peg in a square hole, than a square peg in a round hole, every time.

Margaret de Haan - MBA, PMP, CSM



Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy



Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds


Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.