When I was asked to prepare this piece on creating and managing requirements, my initial thought was to detail the multitude of ways in which requirements can be captured. The “techniques”. I could cover Unified Modelling Language (UML) and Use Cases; Data Flow Diagrams (DFDs); Functional Decomposition; Entity Relationship Diagrams. All these “techniques” are well documented elsewhere. What seems to be missing is an appreciation of the difficulties involved in a real life situation. What happens when a Business Analyst comes to a project and tries to put some requirements together? What does a Business Analyst need to know before they become experts in the “techniques”?

It seems to me that the “technique” you use will be decided by either your own personal preference, or a dictate from the organisation. If all requirements in the organisation are captured as Use Cases, then Use Cases it shall be.

In this chapter I want to highlight six of the most pervasive reasons why projects fail. For each reason, you’ll get an explanation of the reason, how it happens, what the warning signs are, and what you as a project manager can do about each of them. So let’s get down to business. As an experienced project manager, chances are you’ve experienced some of the above situations at least once and can probably add several of your own bullets to the list. If so, then this unit is for you.

Unfortunately teams don't just happen. In practice many teams never achieve the synergy essential for teamwork to become multiplicative - creating something more than the sum of the parts. In fact some teams can become subtractive - the teams producing results less valuable than its members would have achieved if they worked separately.Yet rarely do we come across project plans and resources that account for the need to have an effective team in place and even rarer a business and sponsor that supports and encourages the Project Leader to build one.

Instead the requirement is often to" just get on with it" - to demanding deadlines. This frequently backfires, with Project Leaders and teams feeling compelled to immediately dive into the detail of the task, before they have clarified their goals, and with no attention paid to whether the team is capable and committed enough to work together.

Result, the rich resources of a team are diluted into one task focused leader and disengaged under utilised Team Members watching on the sideline.

This chapter is focused upon the vital but often neglected part of project management, that of converting the people working on the project into a team. It introduces the high performing team, what it means to belong to and lead one and then using extracts from our work provides some practical tips on how this challenge can start to be met.

This chapter is about understanding, identifying, and managing the political aspects of project management. Project management goes beyond techniques to complete projects on time, scope, and budget. Improving organizational performance depends upon getting more accomplished through projects. Just what gets accomplished and how comes under the purview of power and politics. Organizations by their nature are political. To be effective, project managers need to become politically sensitive.

Assessing the environment, rethinking attitudes towards power and politics, and developing an effective political plan are foundation steps. These help to address the power structure in an organization, identify critical stakeholder levels of trust and agreement, develop a guiding coalition, and determine areas of focus—actions that take place on all projects and especially in a project office.

In today’s fast-paced, knowledge-based business world, it’s not uncommon to see project managers juggling as many as 10 IT projects simultaneously—with all types of complexities, durations, and sizes. Often, project managers handling multiple projects are simply overloaded or frustrated, and some wish for better days. But how successful are you when you face the juggling act? For starters, success in managing multiple IT projects (i.e., program management) requires that you look at three key strategies...