On bid projects, a poorly managed transition from the sales team to the service delivery team can put the engagement at risk even before the kickoff meeting. Here is advice on what, how and when information should be shared during and after the sales phase in order to align expectations.
Rigidity, late-blooming requirements conflicts, triangular relationships and simple geography conspired to deliver half of what a major technology project promised. On this effort, it seemed, you could change everything but the way the team worked.
Requirements? We don't need no stinkin' requirements. If he’d been an action hero instead of a project manager, Christopher Johns might have done a slow motion leap across the table during a high-powered client meeting and muzzled the executive who was committing his firm to the impossible. Instead, Johns had to settle for writing a humorous commentary about the experience two years after the fact.
Project managers must constantly clarify the requirements behind the faster-cheaper-better mandate, and negotiate their relative importance to the project. Here is a framework of inquiry, applied to three seemingly straightforward initiatives, that calls out the non-obvious contradictions in this ubiquitous mandate. On your real-world projects, this exercise could prove to be a "better" way to meet expectations.
On software projects, nonfunctional technical requirements such as performance, security and reliability must be considered throughout the development lifecycle, regardless of the methodology you follow. Here is a primer on defining these requirements, and best practices for avoiding some common pitfalls.
One of the most difficult phases in project management is gathering business requirements. Many stakeholders simply don't know how to articulate what they want, or why they want it. Project managers who build trust will get better results.