PM Network

Offshore Agile Isn’t the Problem. It’s the Solution.

By | Blog, Uncategorized | No Comments
offshore team working virtually

graphic courtesy pictofigo.com

The honeymoon is over. Looking to deliver more while spending less, just about every large company has engaged in distributed offshore projects over the last several years. But organizations are discovering that outsourcing carries more pain than was promised. More projects are suffering from quality issues, language gaps and woefully unmet expectations. So what can we do? Here are some ways that Offshore Agile projects are overcoming some of these side effects:

Forced Collaboration

Agile project management places a strong emphasis on collaborative communication. Using written English can sometimes mitigate language issues, but email takes too long, and large documents can be stale the moment they’re sent. Instead, we augment project communications with standard processes like a daily call, team chartering, and working agreements. To make that more feasible, teams are using modern online collaboration tools such as Google Docs, instant messaging, discussion boards, and Skype. Some teams have always-on webcams so each side can see what’s happening on the other. You can’t have successful projects without some kind of interaction. If time zones make that inconvenient, share the pain, with each worksite taking a turn after-hours. In short, agile methods expect you to work hard to communicate in real time. You’ll develop stronger collaboration, which will yield greater understanding and more innovative results.

Get bad news early

A mentor once told me, “Never surprise your boss.” Similarly, a good project manager wants bad news as early as possible. One of the greatest pain points for distributed projects is unmet expectations. Sponsors can spend significant time and money generating rigorous requirements, wait a year to see any output and then receive a single large deliverable that simply misses the mark. If iterative-incremental delivery is a good risk-management practice for local projects, then it’s absolutely vital for distributed projects. A monthly demo using a virtual meeting platform can reveal problems and opportunities earlier in the game. If it reveals a slew of defects, the sponsor can reprioritize debugging over adding new features. If an incremental deliverable is built to off-target specs, the sponsor still has the opportunity to swap some of the pending features for the needed refinements.

Formalize Problem Fixing

Conventional offshore projects rely heavily on up front planning, to minimize the pain associated with distance, silos, and time-zones. However, no amount of planning can account for surprises and mistakes. This is why Agile methods formalize policies around fixing problems and changing course. Demos give a chance refine the scope for optimum value. Retrospectives give voice to issues that need escalating. Transparent metrics reveal issues that need to be analyzed further. In short, agile processes require you to pay attention to the issues that crop up on virtual projects.

Now It’s Your Turn

As it turns out, I’ve written a whole minibük on this topic, which you can download for FREE here. It goes into more detail on both insights and tips. Check it out and then post a comment or send me a line: What has worked for you in making the most of offshore, distributed, virtual project situations.

[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]

Bad Requirements? Actually, that’s your fault

By | Blog, Uncategorized | No Comments

I’m growing weary of project managers whining about bad requirements. The truth is, no one can possibly be surprised. From research studies to high-profile disasters, we hear over and over that incorrect requirements and poor scope management are key reasons projects fail. If we know this is a recurring problem in project work, why do we mindlessly continue engaging in the rote repetition of what doesn’t work?

crumpled requirements document

I’d like to share some suggestions to keep us from stumbling over the same mistakes:

Surrender the pipe dream of complete requirements.

There’s always going to be one dependency missed, one person we didn’t interview, one nuance hidden, one more thing we wished we had known. Don’t fall into the trap that more is better or you’ll never get started.

Always assume the initial requirements are wrong.

Sometimes the scope is inappropriately slanted toward one executive or maybe hasn’t been properly vetted. Sometimes the bulk of the requirements are actually “nice-to-haves.” Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure that you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with your sponsor to refine it.

Accept that all requirements change.

Traditional project management culture portrays change as a necessary evil, like traffic laws: If drivers did everything right, we wouldn’t need them. To mitigate the “risk” of change, we install intimidating change-control boards and financial penalties. But what if the work you’ve been implementing for the last two years is no longer relevant to the market? Does it make sense to have your customer continue paying for what is now essentially a useless output? Not in my estimation.

If we accept that our requirements are incomplete and incorrect, then we need to edit them to reflect reality. Indeed, PMI’s Guide to the Project Management Body of Knowledge (PMBOK® Guide), warns:

“Due to the potential for change, the development of the project management plan is an iterative activity and is progressively elaborated throughout the project’s life cycle.”

Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with the customer to refine it.

Simplify your change-management approach.

Agile project managers explicitly embrace the value of responding to change, and institute project policies accordingly. Start by implementing a contract that supports authorized change rather than penalizes it. At the start of each project phase, mandate a high-level yet thorough revision of priorities. If your sponsor has difficulty determining priorities, coach him or her through the tradeoffs. Once changes are accepted, update your metrics to match the latest details. And while you’re at it, be proactive in communicating the latest details to everyone involved in the project.

Now it’s your turn:

What patterns have you seen around bad requirements? What have you done to minimize the pain or ensure the right things get done? Leave a comment below and share your own experiences.

[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]

Agile experts say the stupidest things

By | Blog, Uncategorized | 5 Comments

It drives me crazy. I heard an agile consultant this week say, “We’re trying to force the client to track progress they way we want her to”. Really? Good luck with that.

People tell me over and over the things self-appointed agile experts have said, and when you think about it, not only do they violate the spirit of the agile movement, they just sound silly. Tell me if you’ve heard one of these before.

“Our project will succeed only with a full and immediate implementation of an agile methodology, and its associated project tracking software”.

 The official definition of the agile movement can be found at agilemanifesto.org, which explicitly values Individuals and Interactions over Processes and Tools.Granted, a shrink-wrapped set of people-friendly policies can be a good foundation for transforming a losing team into a winning team. Indeed, I actively promote both the Scrum methodology and the PMI-ACP certification as good things. But that does not mean just doing those things will automatically improve team performance. Instead, a true agile practitioner will ask simple breakthrough questions: Are we all on the same page? What agreements can the team install and self-enforce, to address those gaps? How can we customize our current methodology to support those agreements?

As I’ve mentioned here before, the methodology doesn’t matter. What matters are the principles you embrace towards delivering your project.

“We’re agile now, we don’t do any project documentation”.

 This common myth is seeded in the manifesto’s favoring of Working Software over Comprehensive Documentation. Granted, many projects waste money on piles and piles of reports that nobody reads. But, that does not mean we throw everything out the window.

Instead, a true agile practitioner will seek to understand why those documents are mandated. Sometimes, a better specification can often improve the quality or accuracy of the final deliverable. Sometimes a risk register or Gantt chart can help increase credibility and stakeholder support for a project. The document doesn’t matter; what matters is that we address the underlying need.

“Fixed-price contracts are immoral. All our projects will now be time-and-materials.”

 This is a fanciful interpretation of the agile manifesto stating its preference for customer collaboration over contract negotiation. Granted, many projects are launched as the result of zero-sum negotiations leaving a project team underfunded and understaffed. But that does not mean we refuse to have the conversation.

Instead, a true agile practitioner will strive to forge a positive working relationship with her sponsor with deeper questions: What are the client’s concrete business goals for this project? If push comes to shove, can we achieve the goal with only half the features to stay on schedule? Is it possible more budget would be approved for extra safety reviews?

Fixed-price doesn’t matter. Several people have offered agile contracting structures that support what does matter: a positive working relationship around project goals (for more info, see my PMI webinar on the topic of Agile Contracts).

“We’re agile now, so we don’t have to estimate. The project will be done when it is done”

This delightful gem is inspired the value the manifesto places on responding to change over following a plan. Granted, many projects are mindlessly judged on budget and schedule, regardless of how bad or how wrong the deliverable is. But that doesn’t mean we stop planning altogether.

Instead, a true agile practitioner will generate as much meaningful data as possible about our health of our project: Will we run out of money before we achieve our goals? Does our sponsor have enough data to make hard trade-off decisions? As General Eisenhower said “plans are worthless, but planning is everything.”

“That’s not agile.”

Guest what. I don’t care what you think is agile. I care whether we’re going to deliver. In the end, a project is judged not on the mechanics used, but on the objectives met. The agile movement was launched as a reaction against a focus on bad mechanics. If you’re falling in love with your agile mechanics as the silver bullet, then you’re dangerously close to losing your agility.

What about you? What silly things have you heard agile people say, often in direct contradiction to the Agile Manifesto?

[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]

small house in person's hand

Want successful projects? Do less work

By | Blog, Uncategorized | 6 Comments

The most dramatic cause of project overruns is that we are doing more work than is absolutely necessary to achieve the high-level scope statement. But you can be the exception. Do not simply accept the project plan handed to you. Facilitate true innovation, which is delivering the most valuable business results from the least amount of work.

Read More

Just Enough, Just In Time, and Sometimes Just Because

By | Blog, Uncategorized | 13 Comments

“How much up-front planning should we do? How many people should we hire? How many meetings, documents and procedures do we need?”

No matter what field or what project, we all face the “how much?” questions over and over. To avoid getting bogged down, project managers should heed three golden rules: Just Enough, Just in Time and Just Because. I first heard these from Mike Griffiths, PMP, one of the earliest council members of the PMI Agile Community of Practice, when we were struggling with a lengthy document. After much debate, Mike interrupted with a seminal insight in agile efficiency: “When it comes to documents, I coach my teams to generate just enough, just in time and occasionally just because. I think this document fits the last category. Our client has asked us for this document, and even if we consider it excessive, the project will simply never get launched unless we use it.”

Let’s take a closer look at these three tenets of agile productivity:
Just Enough
GOLDEN RULE NUMBER 1: Just Enough. Only do enough prep or support work to achieve the primary goal of delivering business value. The problem is that we so easily intertwine this work with the bottom-line deliverable we’re paid to generate. With that confusion comes the temptation to do more prep and support work than is necessary or required.

Yes, we need a project roadmap, but rather than spend time building a yearlong plan down to the hourly resource requirements, we’re going to provide just enough detail to communicate a vision to stakeholders.
Yes, our IT staff needs some technical direction, but rather than waiting to architect every layer of every interface of every system up front, we’re going to provide just enough direction to get started.
Yes, we need to pass the certification and accreditation audit. But rather than defensively launching an avalanche of paperwork, we’re going to collaborate with the auditors to deliver just enough documentation to satisfy them.

Just In Time
GOLDEN RULE NUMBER 2: Just in Time. You could be crafting lightweight documents, lightweight architecture and lightweight processes, and still be doing all that lightweight work way too prematurely. Of course we could need that architecture component, but let’s invest the time to implement it only when we know for sure we’ll need it.

Of course we’ll need a detailed action plan for next year’s project phase, but let’s devote time to crafting that detailed plan when we get to that phase.
Of course we’ll need to generate some documentation, but let’s wait until we get the documentation requirements before we waste our time on unnecessary write-ups.

Just Because
GOLDEN RULE NUMBER 3: Just Because. This is the constraint that keeps us grounded in reality. I know the 40-page template violates “just enough documentation”, but we’re going to use it, just because we won’t get sign-off without it.

I know forecasting the full project cost up-front violates “just-in-time planning,” but we’re going to do it, just because we won’t get funding without it.
I know triple-entering our hours into the timesheet system violates “just enough administration”, but we’re going to do it anyway, just because we won’t get paid if we don’t.

The next time you’re faced with a dilemma over “how much” of something you should do, rely on these three rules to generate an agile response.

[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]