Our organization is EXTREMELY limited in the approach to proper project management. Projects do get accomplished, but other times they do not. Those that do get accomplished tend to take longer then they should.
We are now implementing a PMO and getting others, such as myself, trained as project managers. Please understand that we are in our infancy, so some of these questions may sound very elementary.
Because the culture is changing, some in IT are relunctant to give up their ways of doing things. One of them is to understand the process and sequence of events. Since I'm new, it's difficult to explain certain aspects to them in an understandable manner. One of those is creating the WBS and schedule. Some have stated that they can't create the WBS or schedule until they know the requirements. I don't understand this because the requirements gathering doesn't happen until the execution phase. Whereas the WBS is created in the planning phase.
Any thoughts?
Thanks! Saving Changes...
Sort By:
Don KimPROJECT-TO-PORTFOLIO MANAGEMENT EXPERT| Seeking opportunitiesSacramento, CA, United States
Well, if we look at this from the PMI/PMBOK perspective, what people in the IT industry call requirements is what the PMBOK describes as "scope".
The scope statement is one of the main inputs to the develop WBS process. And one of the main items to be completed before the scope statement, is project management plan, whose main inputs are the project charter and preliminary scope statement.
This makes logical sense, as you would need to know what comprises the scope (requirements) of the project, before you can start to decompose the tasks into the WBS and schedule estimates.
But keep in mind, the PMBOK does acknowledge that you will most likely not have all the scope known ahead of time (actually in all my PM experience, I've never had all the scope known ahead of time!), and thus advocates progressively elaborating the scope during the planning phase, and integrating scope additions and changes to your schedule and WBS.
My advice given your current situation, is to not get too involved with arguing over which process is suppose to get completed first and try to define this too literally based on things like the PMBOK or other methodologies.
Here's what I'd suggest:
Initiation Phase - Get a project charter done, and solidify what the one main driver of the project is, what the constraints are and floats you will be able to work with. As the PMBOK suggests, try and get a preliminary scope statement started here, so that you get a high level view of what the scope is.
Planning - Get you team together with the project charter and preliminary scope statement completed, and use something low tech like flash cards or yellow stickies and get your team involved with writing out a rough schedule and WBS.
Another technique I like to use from the Scrum school, is to create a prioritized backlog list of tasks to help with the development of the WBS and schedule. This can be as simple as listing the tasks down in Excel, assigning a priority number to each, then just using the sort function to sort the priorities.
Main thing is to get you and your team involved, start with something practical and low tech, and use iteration and progressive elaboration to find tune the schedule and WBS. This should be a good way to start getting you organization into a centralized project management mindset.
Since you've got an impressive profile, I'd like to take the opportunity of getting a few advices from you on the PMO initiative. I am working on the same.
The problem goes like this: we are in the implementation planning phase for setting a PMO in my department. Our company is already rated at CMMI L5 but project management practices are being ignored in our dept. Projects get completed but they usually are behind schedule most of the time. The problem is that the project managers dont have a realization for this although they admit to themselves that ignoring PM processes leads them to this problem every now and then.
For the PMO implementation, I have already done most of the work; defined the PMO workflow Model (as processes are already in place in our org), defined roles & responsibilites of the PMO personnel, Described all the coordinating functions, proposed the new organization structure after implementing PMO.
Now the problem lies with acceptance by the middle managers coz rite now they are important for the senior management. Since I've proposed a Strong PMO model, which directs the execution of projects; the already existing PMs dont agree to it and that is the major hurdle for me. Now i'm stuck in the middle and I dont know how to convince them. I dont want a consulting PMO Model to be developed whose job would only be to support the project teams and managers in documentation and some clerical job, which would bring no significant improvement in terms of cost and schedule. Because previously we were already living in a consulting PMO.
I really need a sincere advice. Saving Changes...
Don KimPROJECT-TO-PORTFOLIO MANAGEMENT EXPERT| Seeking opportunitiesSacramento, CA, United States
Hi Khadija,
Looks like the main issue you have is getting management buy in and cultural adoption. I'm facing similar type issues in my own organization and I'm sure many if not all large organizations are facing similar issues.
But unlike others, your organization is already rated at the CMMI level 5, which means you have an extremely mature process for your IT processes, and now need to align this with your PM processes. I think you already have a head start, since you don't have to convince them of the importance of mature and repeatable processes.
What you need to do now is provide a real complete business case for adoption of a PMO model. It would be impossible to go in depth about this topic here, but below I have probably one of the best books I've read on how to go about this that I would highly recommend to you:
This book goes over how to initiate, implement then manage a PMO from start to finish, and gives some great advice on how to overcome the barriers.
Since you are CMMI L5 rated, the following reference book by PM guru Kerzner maps out a way to intersect CMMI assessments with project management processes into a kind of hybrid PMMM (Project Management Maturity Model):
Don,
Thanks a lot for your help in this regard.
Actually, I have already gone through the first book that you mentioned and found it quite helpful. I had already done my homework after consulting the book. But the problem is that my boss first wants me to get the workflows reviewed by the middle managers and then go for writing the Detailed Business Case. That Case would then be reviewed and approved by the senior management. But the middle managers are not ready to listen to anything. Now, unless they are not mentally prepared for the change, I cant get the workflows wet by them. You are right that my main issue here is getting management buy-in.
The thing is that I have a clear direction but no management support. In a culture like yours, maybe accepting change wont be that difficult. But here things are the opposite. What is it that I'm seriously lacking here and need to bring in to work things out? Saving Changes...
Selva Saravana PuvananthiranDelivery Lead Senior Manager| Accenture Solutions Private LimitedChennai, Tamil Nadu, India
My two cents...
There is a saying "Seeing is believing...". Is it possible for you to choose a current situation in a project and walk them through the current processes and the new workflow that you are working on? This will help them understand the difference between the two models and help them choose one over another. However, I do not know how easy is it in your organization to do something like this?
