Journyx Project Management Blog

How to Work Together

The best way to help your PMO to become more agile, and vice versa, is to get these groups together and focus on their similarities instead of their differences. For example, both groups are interested in prioritizing projects to ensure that the most important ones receive adequate resources and budget. They are also concerned with project execution, though their definitions of success might vary between staying within budget and time constraints and meeting customer expectations.

When it comes to a difference of opinion, compromise is necessary. Creating an agile PMO in your organization will take a bit of diplomacy and mediation. It will be necessary to find ways to get each team to give a little ground for the greater good. For example, the PMO can compromise by being flexible and open to altering plans and schedules as needed, while agile developers can compromise by tracking their time in order to keep everyone updated on their progress.
Organizations with both PMPs and agile developers should not hesitate in getting these two talented groups to work together. With the right kind of management processes in place, managers can capitalize on the strengths of each group for successful project execution and increased return on investments.

Agile Development Is Here to Stay

Agile development continues to gain popularity in the IT world for a number of reasons. One of its key principles is constant communication between developers and customers, which helps in maximizing customer satisfaction and managing scope creep intelligently. Recently, an executive at a well-known financial institution told me that agile is important because it allows developers to build and demo often, enabling customer advocates to note when something needs to be corrected.

Agile allows companies to keep their fingers on the pulse and adapt themselves to the needs of customer or the market very quickly. “Agile teams are cross-functional, self organizing and self managing,” Sulaima asserts. With principles such as these, it’s not difficult to see how agile development teams can be extremely effective.

Joint Business Value

Combining the strengths of the PMO and the development team is a smart move. With a PMO to keep an eye on things, project risk can be managed much more effectively. Problems along the way are recognized and often resolved in a timely manner. In addition, the agile group can help the PMO to become more flexible and customer-oriented. Recently, Evan Campbell, CTO and agile devotee, was quoted in a project management article as saying,

“A strategic PMO can be a great asset to agile teams,” notes CTO and agile devotee Evan Campbell in a recent article, “[... by] keeping an eye on performance of company assets in the portfolio and working with the product owner and scrum master to make sure the metrics of projects are assessed and value is delivered.”

Agile development is often interpreted as completely at odds with the structure and constraints of the project management office (PMO). Yet it does not have to be this way. Creating an agile PMO that bridges the gap between these two significant groups can help organizations to prioritize projects and allocate resources much more effectively. Here’s how to keep both project managers and agile developers happy while leveraging the strengths of each for successful project execution.

Who Needs a PMO Anyway?

The PMO brings significant advantages to the organization. For one thing, its focus on metrics is often crucial to the health and success of a project portfolio. It can also facilitate communication between project team members, project managers and those higher up in the organization. Tamara Sulaiman, a project management consultant, explains it this way:

“Let’s say you are a manager or leader in an agile organization. Your development teams have implemented Scrum and are now working toward release. You’ve got the Scrum of Scrums working so that teams can communicate with each other about cross-team dependencies and impediments on a daily basis. But there’s a gap, isn’t there? As a manager, how do you effectively and efficiently measure progress, manage risk and keep your eye on the big picture across these agile teams? Wouldn’t it be great to have an easy way to communicate budget and schedule information at the program level to the organization?”

While the agile worker is focused mainly on development at a fast pace, the PMO can help to keep the rest of the organization informed about what is going on. Scope changes, delays or quality issues can arise at any time, and when they do, they must be communicated to all of the stakeholders who can adjust expectations accordingly and take the appropriate course of action.

Let’s finish off our week of focusing on IT Projects with a CIO article that offers some keys to success that might be overlooked by project managers.

What’s the recipe for project management success? Many IT professionals agree that buy-in and support from top management, clearly defined scope and requirements, good communication, and the right project resources top the list of key ingredients.

Those aren’t the only factors influencing the successful outcome of a project, of course.

According to 83 members of the CIO Forum on LinkedIn, here are some “less-considered” keys to IT project management success:

1. A Clear Definition of Success
2. A Willingness to Make Unpopular Decisions
3. End-User Training and Hand-Holding After Go-Live
4. Clearly Defined Roles and Responsibilities
5. Transparent Workflows
6. A Process for Managing Scope Changes
7. Risk Management
8. Adequate Documentation
9. A Good QA Process
10. Project Governance

Can you think of any other factors that are often overlooked, but impact the success of projects nonetheless?

In continuing the series, here are the highlights from Schultz’s newest article on change management and technology for managing IT projects successfully.

11. Change Management

Good – I lead the project team in addressing the introduction of new business processes and their impact on staff.

Bad – The project team is not introducing new business processes, despite my encouragement as project manager, to place more emphasis on this topic.

Ugly – The project team doesn’t believe change management is required.

12. Project Technology

Good – The project consistently uses a short list of technologies. I can conceptually describe the technology.

Bad – The project uses an extensive and changing list of technologies. Initially it was Microsoft; some months later it’s Java and more recently something called LAMP is being discussed.

Ugly – I observe the project team using lots of technology buzzwords in discussions. It’s not clear what technologies the project is actually using.

Anything you would add to Schultz’s lengthy list of factors that go into IT project success?

As you might remember, we’ve been following Yogi Schultz’s Project Times series on what it takes to execute IT projects successfully. In Part 1, he discussed project goals and sponsors. In Part 2, he focused on the project manager, benefits, plans, status and budget. Part 3 gets into some new issues:

7. Project Organization

Good – I’ve created a reasonably clear organization chart with names and titles.

Bad – I’ve created more than one organization chart with many lines. Some names or titles are missing.

Ugly – I’m not clear who is on the project team.

8. Project Resources

Good – Most individuals on the project organization chart are assigned full-time and are employees.

Bad – More individuals are part-time or contract staff than are full-time employees.

Ugly – We’re using the virtual resource concept.

9. Project Steering Committee

Good – I ensure that key business areas that will be affected by the project are represented on the project steering committee.

Bad – The committee doesn’t exist as far as I, as project manager, can tell.

Ugly – Committee membership is unclear to me or meetings are sporadic and/or offer little content.

10. Stakeholder Communication

Good – I’ve ensured effective communication to the various stakeholders.

Bad – The communication to the various stakeholders that I’ve witnessed is sporadic.

Ugly – I’ve not observed effective communication to the various stakeholders.

Remember when we posted about the competition between scrum and waterfall? Elizabeth Larson is back with a second part to her article on which method is “winning.” In this installment, she highlights the similarities between the two:

1. Both have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
2. Both stress the importance of communications.
3. Both allow for more or less rigor, as appropriate.
4. Both find communications easier when the teams are co-located.
5. Both face more challenges with virtual teams.
6. Both have processes to manage the scope.
7. Both estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.

She also gives waterfall the advantage in a few scenarios, including effectively using the role of the BA to define requirements, defining the business need and business case, and getting from the “as-is” to the “to-be.” Do you agree?

The most common result of this ‘evolution’ is that a lot of current projects are being carried out, yet no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon. The way to solve this is to increase awareness, including:

1) A recognition that IT projects do not belong to IT, they belong to the enterprise as a whole, even if various non-IT parts of the enterprise are assigned responsibility for some sub-set of projects.

2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the enterprise’s strategic plan.

3) The realization that dozens or more project ideas may be in play at any one time, but the average enterprise does not have the resources to do them all. It must pick from the candidates which projects will indeed be resourced and proceeded with, and it must continue to do this as current projects are completed and resources are freed up.

It all boils down to best use of limited resources. The term that has emerged to describe all this is Project Governance.* The most common analogy used to describe this governance is “gating”: a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, while the rest wait for another chance when more resources are available or are eventually dropped from consideration.

It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development (commonly called Construction). As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the enterprise.

–

*In some ways, governance of IT has emerged a lot sooner than the newer Corporate Governance that deals with all aspects of a company’s operations in order to meet with new compliance laws brought around by the Enron failure and the like. Many IT departments already recognized they had their own mess to deal with, hence Project Governance.

David Wright has been an IT Business Analyst for 25 years and is the author of Cascade: Better Practices for Effective Delivery of Information Systems in a Multi-Project Environment. You can find more of his writing in the latest issue of Cutter IT Journal and at his blog, Business Analysis. You can also follow David on Twitter.

IT projects have rightly earned the reputation over the years as places where lots of money goes in and no value comes out. We are all aware of the CHAOS studies by the Standish Group that show that most IT projects are also usually late, and a large number are never even completed(!).

How did this happen? My (untested) theory is that computers were first used to automate rote manual tasks, and the results from these projects were valuable and easily seen as so. This led to the belief that automating most anything was going to be good for the enterprise, but as projects moved into more complicated/complex aspects of the business, the returns of pure automation began to diminish. Unfortunately, it was still assumed that the value was there, and it was a complete assumption; actually determining what the value was to be was done only rarely.

Early computer projects were really run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well, so the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.

So, projects proceeded into more complicated areas of the business, and they started to break down. Some failed, and now management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable). How did they all get started anyway?

Come back on Friday for Part 2 of David’s post on choosing the right IT projects!

David Wright has been an IT Business Analyst for 25 years and is the author of Cascade: Better Practices for Effective Delivery of Information Systems in a Multi-Project Environment. You can find more of his writing in the latest issue of Cutter IT Journal and at his blog, Business Analysis. You can also follow David on Twitter.

Project Times has published an article by Elizabeth Larson on the competition between the two types of software development processes, agile and waterfall.

I think people like a good fight. Certainly the media seems to, as is evident in the world of politics, sports, and entertainment to name a few. In the world of business analysis the current fight seems to pit Agile methods against the Waterfall approach. For the next several blogs we’ll have a Scrum vs. Waterfall match. In corner #1, representing the Agile methods, we have the Scrum framework. In corner #2, representing Waterfall, we have the “traditionalists.”

Larson awards both rounds to agile. Why? It allows the team to adjust estimates and deadlines based on real feedback and progress, and it makes things “easy and practical.” Agile is clearly gaining ground in the software development and project management worlds, and it shows no signs of stopping.

–

Related stories:

E-Commerce Times: How to Create an Agile PMO

gantthead.com: The Agile PMO Role

Projects@Work: Agile Rising