Companies spend a lot of time and effort establishing PMOs and devising project methodologies that enable them to deliver their strategic initiatives. Often, such initiatives span the length and breadth of the organization, are complex in nature, and are extremely cross-functional in their implementation. It is common for such projects to run across three domains: commercial, technology and support. This poses a great challenge for executives in appointing the right type of project manager to take the helm of responsibility and delivery, which naturally leads to a typical discussion about how such projects should be organized. Figure 1.0 illustrates a common project organizational chart that is used to deliver end-to-end (e2e) initiatives.
We spend a lot of energy in project management circles trying to determine how to do one thing or another. In my travels to various parts of the planet, something that’s sadly lacking in many places is good judgement on whether we should do that thing.
I’ve told the story before of an engineering organization that was looking for a new timesheet system. This sounded like good news to me because our own TimeControl timesheet system is a good fit for engineering firms. However, I was less happy when I heard the reason why the customer felt their existing system was no longer able to meet their requirements.
“We’re having to do a whole manual transfer of data from that old system to our Finance ERP,” explained the technology specialist. “Because they need three rate values and our existing timesheet can send only two, we’re having a miserable time with all this manual intervention trying to get a third value stored and sent. Can you do that with your TimeControl?”
I call projects like this “a dangerous opportunity”. I inherited a troubled initiative, which not only did not know what they were really trying to deliver, but they were delivering badly.
My client contact was under severe pressure from the parent company to fall in line and develop a multifunctional enterprise computer system from scratch. Application software packages wouldn’t do because they “already looked at them”. And of course the project was “to be completed yesterday” To make matters worse, my client’s boss was an exceedingly intelligent and charismatic individual who lacked experience, yet had the dominating, strong-willed and demanding presence to prolong the project damage.
There have been some changes to the PMBOK® Guide in the Fourth Edition. Since the PMBOK® Guide is an ANSI standard, PMI must assess it every 4-5 years to determine if an update is needed” (Cyndi Stackpole).
The increasing acceptance of project management indicates that the application of appropriate knowledge processes, skills, tools and techniques can have a significant impact on project success. The PMBOK Guide indicates that subset of the project management body of knowledge generally recognized as good practice” (PMBOK Guide ®3rd Edition, 2004).
It is clearly stated that the PMBOK Guide® is a subset of the project management knowledge and the field of project management, like many other professions is too vast to be captured in a single book or guide.
Project managers have the difficult task of bringing together a team and delivering something exceptional, often within a tight timeline and budget constraints. In these pressure situations, project teams need to be able to perform together as optimally as possible. While newly formed teams often need time to establish their rhythm and develop efficient processes, even an experienced team with several projects under its belt can probably find ways to make their work get done more efficiently. With the seemingly constant demand to find better ways to do things, how can a project manager properly invest time to get a team to perform better?
Every fall, my family and I plan a trip to visit one of the many apple orchards in southeast Michigan. Our day is spent on a tractor, going to the many fields of trees to pick some of the finest apples in the world. We fill our basket full of good, fresh apples. In choosing our apples, we generally will pick the best-looking apples. These apples are mostly on the tree and in some cases they have already fallen to the ground. Any blemished or bad apples we will not pick.
After carefully picking our apples, after a few days we discover some apples are going bad. If a decaying apple is left in the same position and allowed to stay with the other apples, it will affect the apples around it and they will start to deteriorate. If not careful, you could end up with a bunch of bad apples.
‘Call up your CEO and then count the number of seconds before he recognizes your name...’
If your PMO is really connected to the business, at the right level and with the right profile, then your CEO will know you and your PMOs work. You don’t have to start with the CEO, you can try this out moving up the organisation level by level – who at two levels above you knows you and the PMOs work? For those that do say ‘thanks’ and for those that don’t; well tell them about it.
In Part 1 of this series, I shared four best practices that can help you lay the foundation for a successful project. In this installment, adapted from my book Practical Project Initiation, I briefly describe eleven practices that are useful for project planning.
Practice #5: Write a plan.
Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is doing the planning—thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you encounter later in the project.
A useful plan is much more than just a schedule or task list. It also includes:
Heated discussions about relationships between a project manager (PM) and a business analyst (BA) are often focused on their non-aligning sides rather than on their mutual efforts to ensure project success.
I tend to think about PMs and BAs working together in projects as two hands carrying a baby. Here is my view on the PM-BA tandem and how it comes together to make a project successful.
In a recent study, the Accept Corporation and the Association for International Product Marketing and Management (AIPMM) found that more than 60% of executives say they struggle making kill/go decisions. For some reason there is a tendency to continue projects and activities even when most people involved realize it’s not an optimal use of their time. Organizations generate a cultural momentum that, like a battleship, won’t turn easily or quickly even when the product team is aware of the issues. What causes this culture to develop? Are poorly aligned project incentives causing a proliferation of this behavior?