Posts

Programme Management

I’m currently working with a multinational organisation to build out the strategy to empower the business to take advantage of new regulations coming in as a result of de-regulation in Europe (Hmmm). We are working on a Programme to implement the strategy to deal with these changes in our marketplace.

 

For me Programmes are not just a collection of related projects it’s significantly more than that, programmes are about strategy and projects are about tactics.  Programme management is overseeing the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisations strategic objectives.

 

Programmes deal with outcomes and projects deal with outputs (From MSP®). We do use Programme Management to coordinate related projects but that’s down the road and its not the primary reason to kick off a programme. The programme starts by taking the business strategy, targets, initiatives and policies and defining the vision, scope and priority of the outputs that will deliver the outcome.

How do we approach this.

Develop the Vision, this is the postcard from the future of state of the business. It is used as the focus for the programme and like any vision it should be compelling and clear. Failure to get a good visions statement weaken the programme, therefore time should be spent in developing it. Re-design the vision in the middle of the programme may cause confusion.

 

From a Vision we can tease out a target operating model for the future, the practices and process that will be need to be in place to deliver the vision.  The target operating model is the blueprint of the future and the programme manager has the responsibility to ensure that the blueprint is delivered.

 

The POTI model is useful in developing out the blueprint, for each element of the blueprint used it to analyse the processed, organisation change, technology and information required for the future

 

 Detail
Vision StatementWe want to enter new emerging market ABC
                PProcesses, Business Models of operations and functions including operating costs and performance levels
                OOrganizational structure, staffing levels, roles, skills required, organizational culture, supply chain and style
                TTechnology, buildings, IT Systems and tools, equipment, machinery and accommodation
                IInformation and data required for future operations

 

From defining these process, organisational changes, technology and Information the projects to deliver them become apparent.

The above is simplified method bases on MSP®. More details on the methodology is available with templates examples. Drop me a line to chat through it.

Does ‘servant leader’ sound strange to you? After all, does it make sense to talk about leading a team so that it moves forward to achieve goals, while being behind it to tend to the wants and needs of team members? Yet in numerous project management situations this style of leadership can be very effective. What might look like incompatibility at first blush becomes a doubly positive force for obtaining better results faster and more efficiently.

Agile project management methods like Scrum are a case in point. Handling change and rapid development cycles requires intelligence and creativity from team members. Leaders that try to pull rank are likely to do more harm than good. On the condition that everybody understands the basic rules of engagement, the contributions to be made and the objectives to be met, hierarchical levels can be taken out of the equation.

A servant leader then:

  • Assures the well-being of the team and team members
  • Prioritizes his or her own actions to help team members solve problems (without dictating the solution)
  • Focuses on people, on the understanding that well-motivated and enthusiastic people will meet project targets and expectations best.

At the same time, the servant leader is also the lynchpin for communicating with sponsors, stakeholders and other management. This is as challenging as any other leadership approach. That means good servant leaders are usually the ones that have had the right training and experience. And the right training also instills the recognition that servant leadership is one possibility among several, to be applied as and when the situation calls for it.

Make no doubt about it the early scrum (Planning and Daily)  meetings set the tone for all the following activities of the project. With Scrum, life cycles are short and the pace hot with little time afterwards to re-jig team attitudes and behavior.  With the early meeting setting the tone for the rest of the cycles I suggest that you create an additional scrum kick-off meeting.  This can help to ensure that subsequent scrum meeting are focused on the scrum job and not the “ground rules”

This Scrum kick-off meetings gets the getting to know how it works out of the way. Subsequent team meetings will need to be rapid stand-up ‘huddles’ lasting for all of 15 minutes, you don’t want your kick-off meeting to seem too leisurely. Yet you also want to take enough time to set the scene properly for future success. The following tips may help:

  1. Remember that Scrum is also about trusting people’s ability to solve problems. The team may be the best source of answers for some questions that arise.
  2. Make sure your whole project team is there, for full input and engagement. Change the date to accommodate anyone who has a schedule conflict.
  3. Notwithstanding quick-fire project meetings in the future, allow plenty of time for the kick-off meeting.
  4. Make sure team members get to know each other. Fun exercises and games are one possibility.
  5. State or remind the team of how Scrum works and the roles of the Scrum Master and project team members.
  6. Agree on definitions (when is a deliverable truly ‘done’) and project tools (specific project management and issue tracking software, for instance).

When you get steam up on your Scrum process afterwards, remember that from time to time, it’s good to have periodic get-togethers along similar lines to the kick-off meeting. This can be an important factor in maintaining team enthusiasm, cohesion and momentum.

Inside every project manager is an ‘agilist’, trying to get out. In fact, that’s true of everyone in a project team. While the status quo and comfort zones have an undeniable attraction for our lazy streaks, we’re not made to do the same things over and over again. We may be apprehensive about change, but we also need it. The perils of endless repetition include boredom and rapidly increasing error rates. So what’s the answer?

A little root cause analysis will help here. Change is stressful when it involves the unknown. We worry about whether we’ll feel good about what comes after, compared to what we had before. When constant change is a fundamental part of an agile project approach, it can turn into a real tug of war between the urge for variety and the fear of failure or degradation of a situation. The pressures of project sponsors and end-customers for delivery of new products or services then exacerbate the problem.

But good methods for managing change and succeeding with agile methodologies can be learned. Agile project management may be characterized by fast-moving activities focused on action for rapid results. Yet it still relies on well-defined concepts and techniques to work successfully. It can be taught, internalized and then applied with confidence – and therefore without stress or worry – about the quality of the output of each agile cycle. Going agile and embracing change can then become a source of satisfaction for all concerned.

 

When interest levels of the project sponsors drop, it’s bad news for everyone. Bad for the business that has invested resources. Bad for the project manager and team who find themselves without an essential source of support. And bad for the end-user who may then get a product or service that doesn’t meet requirements or simply dosn’t get done.

Perhaps the wrong sponsor was chosen by the business and they were never interested in the first place. In any event is is critical to have and maintain project sponsor engagement, there is no formal methodology for doing so. Some project mangers are afraid to manage upward or don’t quite know how. Teamwork between the project sponsor and project manager is the way to create really effective projects.

Here’s a few suggestions

  • Common sense – Make sure you think your tactics through
  • Understand your sponsors perspective, agenda and how it does or dosn’t align with the project goals
  • Seek to understand why disengagement has set in, workload, disapproval of change, people issues
  • Communicate – as a project manager you are a senior staff member and tackling the head-on may be the way, Let the sponsor know you need the support

If you still cant get a re-engagement don’t undermine the sponsor but perhaps seek out other stakeholders that can provide the necessary support in the organisation. This can be often be done with the permission and support of the main sponsor. Particularly if the disengagement has happened as a result of workload.

If you are still stuck and the project effectiveness is being undermined you will need to go all the way to the top.

 

 

“Just say No.” How many times have we heard that advice? In some situations, it may be the best or even the only course of action. But for customers eagerly pushing for extra features or accelerated delivery schedules for a project, being that blunt could cause problems. On the other hand, appearing indecisive or setting up false hopes may not be a good idea either.

To start with, when do you need to say “No”? In project management, a “No” is often the result of the ‘Iron Triangle’ of features – schedule – resources. If your customer wants a change in one of these factors, then at least one other element must also change. If your customer can’t or won’t accept such related change, then the answer to the extra feature request can only be ‘No’.

Communicating that ‘No’ may be done best by a short, friendly reminder about the current project goals, timeline and investment. Done the right way, a ‘No’ in this case also has two advantages. It shows your customer that you’re on the ball. It also demonstrates that you’re looking out for the customer’s interests, ensuring that the project will be completed on time and on budget.

Are there exceptions? Feature requests and schedule changes might be handled as part of an agile process, with appropriate re-planning or re-prioritization between cycles. But even with agile, sometimes it just has to be ‘No’. In that case, take the opportunity to demonstrate your professionalism and any short-term disappointment is likely to be outweighed by longer term customer satisfaction.