Skip to main content

Tag: PRINCE2

The Good Project Meeting

Written by Brad Egeland on . Posted in Articles. 14 Comments on The Good Project Meeting

I had to laugh at this one. I was meeting with a potential new client this morning and he talked about the concept of the “good meeting” on projects. You know the ones – everyone comes out of the meeting saying, “good meeting!” But when asked what was accomplished no one can really pinpoint anything of any significance.

The really sad thing is this – when that happens for a two hour project meeting with an attendee list of 6-8 individuals, you suddenly realize you just blew through somewhere between $500 and $2,000 of billable time. The PM now has that much less left of the project budget to work with and nothing was accomplished that couldn’t have been handled more successfully in a 5-minute email. Do that weekly over the course of a 6-month project and that amounts to anywhere from $10,000 to $50,000 of worthless, unproductive charges against the crucial project budget for dead weight meetings. Ouch – that hurts.

How do we combat the “Good Meeting”? In my opinion, it is through the following six key activities:

  • Prepare in advance
  • Have a detailed agenda
  • Stick to the meeting timeframe
  • Stay on topic
  • Structure the meeting for maximum participation
  • Perform thorough follow-up

Let’s examine each in more detail.

Prepare in advance. Preparing in advance is just that – advanced planning ahead of the meeting. Don’t just throw together an agenda and send it out. Plan well, think about how you’re going to strategize and discuss and assign tasks to keep the meeting flowing, keep everyone awake, and allow for the best information dissemination possible. You certainly don’t have to go overboard in the meeting planning process – too much would be a waste of time and money – but a little planning can go a long way. You just don’t want to arrive, start leading the meeting, and have everyone feel like you threw it together at the last minute. You want the meeting to be productive.

Have a detailed agenda. Always have a well planned out agenda designed to keep the meeting and information flowing. The agenda is the catalyst to help ensure you have an efficient and productive meeting that will help key decisions happen, assignments get made, next steps get planned and issues get reviewed. This your chance – with all the right key players in the room – to give and get good information. Make the most of it.

A good agenda also helps the meeting stay on track. A meeting that stays on track is one that stays in alignment with the timeframe planned for the meeting, which leads us to the next concept…staying on schedule.

Stick to the schedule. The best way to always have the highest attendance possible, and to gain a reputation as a great meeting facilitator, is to stick to the meeting schedule and agenda you proposed in the advanced meeting communication. Start on time, finish on time, and don’t cancel. Start on time even if you have late arrivals, and finish on time by not allowing you or participants to stray off topic.

And if there isn’t much to cover and it’s your regular weekly meeting, don’t cancel. Better to have a short meeting where not much gets discussed if there isn’t much to discuss than to cancel an ongoing regularly scheduled meeting. If you start to cancel those regular meetings people will start to consider your meetings as “expendable” and “optional” and your attendance will dwindle. Trust me, it will happen. Plus, you never know when something may need to be said even when the project is currently in a lull. If you skip that meeting – even if it ends up only being a 10-minute meeting – a key piece of information that your tech lead has from the customer that you need to hear might otherwise fall through the cracks. And that may have been a critical piece to the project puzzle but it becomes a forgotten piece until it’s too late.

Stay on topic. I can’t stress this one enough. It’s nice that people get together and talk trash or talk about their weekends or work on other projects – but not during your meeting and not on your project time. Plus, they are thoroughly boring everyone else in the meeting who want to be productive and move on to the rest of their day. You don’t want YOUR meeting wasting their time. That’s a very bad reputation to have and a hard one to get rid of.

Structure it for attendee participation. Always structure your meeting – and the agenda leading into it – for maximum attendee participation. Not only will it keep everyone awake and alert, but you’ll accomplish a lot more than those meetings where the facilitator just drones on and on about whatever topic they are providing information on. If all you need to do is disseminate information, do that through emails – it’s faster and more efficient. One-way communication is great for email. But for those things on the project that need to be discussed and decisions made – use the meeting for those. You have everyone together in one room – all the key stakeholders – use that time to make progress on the items and issues that can’t just be handled through one-way communication.

Follow-up after the meeting. Always follow up with notes after the meeting. That way you can ensure everyone is on the same page and everyone has equal understanding of the information provided, the discussions that happened, the decisions made, and the assignments and expectations that were allocated. I like to update the latest status report – usually what I’m using to drive the project meeting and what the agenda originates from – with whatever information and decisions came out of the meeting. I send that out to everyone and give them 24 hours to get back to me with any changes or things they think I may have miscommunicated. Then, I resend the revised info out again to all attendees – and anyone who couldn’t make it – so as to ensure we are now once again on the same page.

Summary

Meetings can be a big waste of time. Or they can be extremely productive. It’s generally up to you and how you plan for and organize your meetings. The better you plan, the more organized you are, the more you stick to your schedule, the better your meeting attendance and participation will be. With all that in place, you’ll be far more likely to have a truly good meeting…not one of those “good meetings” that everyone walks out of looking sleepy and shaking their heads.

Don’t forget to leave your comments below.

Ten Thoughts on Contracting Out Agile Software Development

Written by Richard Hoad on . Posted in Articles. 4 Comments on Ten Thoughts on Contracting Out Agile Software Development

In my company, we operate IT projects under Prince 2 . For some types of software delivery we find agile methods are appreciated our customers. In these cases we use the two approaches in a complimentary way – software products of the Prince 2 project are delivered using an agile method. We find the sweet spot for Agile methods is in-house development where requirements are uncertain, there are changing needs and the development team size is 2 to 6 relatively experienced people.

The 2013 State of Agile Survey results give an industry wide view of the perceived benefits of agile methods, while Rico’s paper on the business value of agile project management , gives an overview of quantitative studies of the benefits. In terms of agile methods my company typically uses Extreme Programming and Scrum .

The advantages of agile methods that we appreciate are:

  • An agile development can effectively accommodate strict time constraints (by number of iterations) and budget constraints (the cost of the team for the number iterations) managing scope (which features from the backlog are scheduled) and maintaining required quality.
  • The discipline of delivering user valued functionality in time bound iterations manages many risks. In a project where the customer has tested and accepted deliveries every two weeks it is difficult to find a sign-off block towards the end. Any deviation from planned velocity is visible from the first iterations.
  • Detailed requirements analysis is done just in time so less time wasted in detailing requirements or features never built.
  • Early iterative delivery sometimes allows return on investment earlier.

We are moving towards contracting out a proportion of software development work. Traditional models for contracting out include time and materials and fixed price delivery. Most of us appreciate the risks of these extremes of the spectrum. In the first the supplier’s economic objectives are clearly not aligned with those of the customer. The second extreme favors inversion of the Agile manifesto ; focusing on artifacts, process and contractual negotiation rather than collaboration, embracing change and working software.

The question many ask is, can we retain the benefits of agile methods when contracting out software development? Others have studied this question including Abogast, Larman and Vodde . The following analysis derives from our use of agile methods in-house and in two tenders for software development recently conducted through the UN Global Marketplace .

The first lesson we learnt in contracting out agile software development (or anything else for that matter), is to align objectives of the supplier and the customer. It is highly desirable to align supplier success with customer success.
The key here is to define the product vision and what must be achieved; foster shared ownership of the goals by treating your supplier as a partner; and consider offering the supplier incentives for meeting key business performance indicators that require partnership with you.

1. In contracting out Agile software development, contract the product vision, define the desired end state and define how completion will be determined.

Define how the project is to be run. Tasks that are done repeatedly in each iteration or sprint become smooth and efficient. Tasks that are left as one-offs for the end of the project contribute to the, “ninety-ninety rule” , and those interminable delays that occur in the last 10 percent of the project.

2. As far as possible minimize the number of one-off tasks by doing them incrementally in each iteration.

Ideally delivered software should be integrated into your environment and your project management methods ready for you to take over control without further effort. We therefore recommend you make your toolset for software development (e.g. source code versioning, backlog management and continuous integration) available to the supplier and require them to use your tools from the beginning. If you have a deployment and quality assurance team, we recommend they do their part in every iteration. We recommend selecting suppliers with a strong ethos of automated testing and test driven development. There is nothing more frustrating for your users than finding the same regression errors in each iteration.

In terms of the agile method, the contract must establish key control points, e.g. how iterations are planned and accepted and the parts of the agile method are mandatory.

3. The contract must define essential process and toolset requirements without unnecessarily limiting the supplier’s freedom to work in the best way possible.

The contract appendices must define conditions for acceptance of each iteration. These will include the tests to be conducted and passed including user acceptance; the standards that must be adhered to (e.g. coding, security, architecture, look and feel, quality, performance, accessibility) and how they will be validated; and what documentation and knowledge transfer is required.

4. The contract must define the conditions for acceptance of each iteration and the overall product.

Do not throw away years of acquired wisdom when authoring the first contract for agile software development. Examine each of the boilerplate clauses your organization typically uses. Clauses on ethical standards, intellectual property, information confidentiality, and maybe even liquidated damages are as relevant to Agile delivery as to any form of delivery.

Related to this, the question of warrantee of delivered software often arises. We recommend warrantee only if the code will not be modified by other developers subsequently. Requiring warrantee will not make proposals cheaper, but proving that a bug derives from the work as delivered can be time consuming.

5. Do not throw away years of acquired wisdom when authoring your first contract for Agile software development.

Some argue that the supplier team membership should be formalized in the contract and changes should be authorized by the customer. On the face of it, this may sound attractive but it dilutes supplier responsibility for the team and the team’s delivery. Our recommendation is to contractually establish the customer’s right to authorize changes to people in customer-facing roles only, and specifically, the scrum master/leader.

6. The supplier should have the responsibility of providing a multi-disciplinary team capable of doing the job.

The contract must provide a mechanism to ensure that both parties are comfortable with the proposed scrum master or team leader.

7. The Scrum Master or team leader will probably be from the supplier side but supplier and customer need to agree that the Scrum Master is suitable and well qualified for the job.

The product owner is another key role and will be nominated from the customer side. They represent the customer and communicate the customer’s vision and requirements and most importantly, from a contractual point of view, ultimately control the backlog.

The Agile Manifesto says, “the most efficient and effective method of conveying information to and within the development team is face-to-face conversation”. Co-location of the team is therefore desirable but not always possible. Sondra Ashmore 2012 examines impact of process on virtual teams on agile and waterfall projects.

Embedding a member of the customer team in the supplier development team by mutual agreement is an often workable one fall back option. This gives the supplier team insights and interpretations; and the customer can get an early heads up of supplier side tensions and problems. It is important that these arrangements do not undermine the role of the product owner.

8. Ensure the product owner knows the Agile method in question, has a stake in the delivery and can dedicate sufficient time and energy to the project and assessment of deliverables. Contractually establish the role and responsibility of the product owner.

We recommend measuring progress counting only fully accepted features when they are accepted at the end of time boxed iterations. The contract must make provisions for how to handle issues such as higher or lower velocity than expected.

At a very basic level, specifying that iterations are time-boxed; setting a minimum proportion of features as a criterion for acceptance of an iteration; and making payment on the basis of accepted iterations or sprints offers the customer a reasonable degree of control.

9. Establish how progress will be counted, the rate of implementation will be measured and the payment schedule.

When software is delivered only after significant investment of time and money, early termination is a huge risk and requires a lot of attention in the contract. With agile methods it is still necessary to consider early termination but exposure is more limited.

Whilst an obvious option is symmetrical right to terminate after each iteration, such short notice may deter a supplier from bidding for, or committing their best resources to the contract. In long projects it may be better to define groups of iterations that arrive at a cohesive state as optional termination points.

It is also important to consider what actions are required with termination, e.g., what becomes of partially developed products or materials provided for the execution of the contract.

10. Establish conditions for early termination and what actions are required by both parties upon termination.

Regarding future plans, we aim to re-use the contracts we have and use lessons learnt to improve our future formulations. We would also be interested in hearing of your lessons learnt in this area.

Don’t forget to leave your comments below.

References
http://en.wikipedia.org/wiki/PRINCE2
http://en.wikipedia.org/wiki/Agile_software_development
http://stateofagile.versionone.com/why-agile/
https://www.projecttimes.com/wp-content/uploads/attachments/rico-apm-roi.pdf The Business Value of Using Agile Project Management for New Products and Services
http://www.extremeprogramming.org/map/project.html
http://en.wikipedia.org/wiki/Scrum_(software_development)
http://agilemanifesto.org/
https://www.projecttimes.com/wp-content/uploads/attachments/agile_contracts_primer.pdf – AGILE CONTRACTS PRIMER
https://www.ungm.org/
http://en.wikipedia.org/wiki/Ninety-ninety_rule
http://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=3267&context=etd The Impact of Process on Virtual Teams: A Comparative Analysis of Waterfall and Agile Software Development Teams

5 Steps to Build Confidence in Your Team Members

Written by Susanne Madsen on . Posted in Articles. 7 Comments on 5 Steps to Build Confidence in Your Team Members

madsen May20How do we build confidence in others?

As project management professionals, one of our most important roles is to bring out the best in our team. This includes not just building a great team, but encouraging collaboration and empowering people around us. We achieve this success by helping individuals improve their confidence and make them see that their contributions and talents matter. The rewards are big—from improved employee engagement and performance to increased productivity. Here are five ways to instill confidence in your team members:

1. Help people learn and develop.

Confidence and competence are closely related. If team members feel that they’re not developing professionally and that their skills are being under-utilized, they’ll quickly begin to doubt their abilities. To increase your team members’ confidence, you have to help them improve and learn new skills so they can play a stronger role in contributing to the project.

One way of doing this is to give your team access to courses, training and conferences. Another way is to give them time to study or to run a pet project they’re passionate about. You can also set up knowledge-sharing sessions to the benefit of the entire team, or even the entire department.

2. Delegate step-by-step.

A great way to build up your team members’ competence—and thereby their confidence—is to delegate specific tasks that will help them grow in an area they’re interested in. Just be careful that you don’t delegate too soon or too quickly; and don’t leave people to their own devices when they’re in new territory. When someone lacks confidence and competence it’s far better to gradually give them more responsibility and to stick close by them until they no longer need you. Your job is to help you team members set reachable goals and to break difficult tasks into smaller steps. In that way people slowly but surely gain confidence as they start to master each step of the assignment.

3. Focus on people’s strengths.

As a project manager or team leader you’re likely to have a fair bit of influence over who does what. You can use that to actively build up someone’s confidence by giving them work that they’re genuinely good at and interested in. People’s confidence (and motivation) will generally grow when they’re given the chance to put their skills into practice and show mastery. The question you need to ask is: How well do you know each of your team member’s strengths. To learn more, check out Tom Rath’s best-selling book, Strengths Finder.

4. Be supportive.

One of the most fundamental ways to boost people’s confidence is to actively support them and build them up emotionally. And one of the best ways to create a strong supportive foundation is to connect with individuals one-on-one. When you do, make space to sincerely listen to their concerns and help them realize how much they have to contribute. When you get to know the members of your team at a more personal level (e.g., what motivates them; what really matters to them) you’ll intuitively know how to best support them.

Another way to demonstrate your support is to actively praise a team member and provide positive feedback when someone does something well. We all like to feel appreciated and it takes so little to say “Thanks, that was a superb job you did.”

5. Embrace failure.

Another great way to build people up is to let them know that it’s OK to make mistakes—as long as they don’t keep making the same ones. When you remove the fear of failure you make people feel safe. As a result, team members open up and are more willing to contribute and experiment. Knowing that they have the space to learn from their mistakes rather than being penalized for them builds their confidence and takes away an enormous chunk of negative energy and worry. Essentially, you free people up to pursue that which is truly important: The successful delivery of the project.

Don’t forget to leave your comments below.

An Executive Perspective on Project Sponsorship

Written by Abid Mustafa on . Posted in Articles. 10 Comments on An Executive Perspective on Project Sponsorship

Over the past decade or so, I have been involved in project work performing a variety of roles. I have led the enterprise PMO and played the role of an executive sponsor, yet there still exists a wide spread perception that executives do not do enough to support the delivery of projects.

The gap between perception and reality regarding strong executive sponsorship for project work is closing but not fast enough. I’ll be the first to admit that executives can do much more to play an instrumental role in seeing projects through to the very end. But project teams must appreciate and understand that executives have a tough job at hand.

In addition to project work, C-level executives in general have to manage corporate strategy and departmental plans, commercials and contracts, financials and budgets, people and technical resources, administration and logistics, and last but not least office politics. Striking the right balance between project sponsorship and these activities is extremely demanding, and all too often the work load takes its toll.

Nonetheless, this should not serve as a pretext for executives to become inactive spectators when sponsoring projects. On the contrary, it can be argued that by managing the company’s work in terms of projects and programmes, executives can optimize how to manage their work load better.

In this article, I would like to address some important points based on my experience that can help executives become good sponsors by providing the right environment for project teams to deliver successful projects and programmes 

  1. Sponsorship must be limited to a few key projects
    The practical reality of active sponsorship requires executives to be engaged in less not more project work. Challenging projects and programmes are often taxing on executive time as they involve several meetings to resolve key issues, make intelligent decisions and provide guidance to project teams. This means that executives at best can get directly involved in two or perhaps three— at best—large projects or programmes at any given time. To expect executives to take on more than this runs the risk of executive fatigue, disengagement and in the worst case lip service. To mitigate such situations the company has to strike a fine balance between its aspirations and its capability to deliver. By introducing a proper project portfolio management methodology and recalibrating the mindset of the company to do less, executive sponsorship will invariably improve.

  2. Learn to use the right language to communicate project work to executives
    One of the persistent challenges that project managers and their teams fail to overcome is ineffective communication with the executive audience. A parlance that is heavily laced with project management terms can be quite off putting and only serves to entrench misunderstandings regarding projects. Likewise content that is heavily immersed in details produces the same negative connotations. Project managers and project teams must communicate in a language that the executives can understand. This should not be misconstrued as using only financial terms to communicate project status updates. Instead, project managers should present project updates by employing terms that the collective executive audience is comfortable with. For example the chief technical officer (CTO) is in a better position to understand project information if the content employs technical terms that the CTO is familiar with. Similarly, the chief financial officer (CFO) will be more receptive if financial terms are used to convey the project information. Hence it is vitally important for project managers and their teams to get to know their executives and how they think and communicate. This will help in the reduction of the communication gap, and through experience, project managers should be able to communicate effectively with the executives.

  3. Thoroughly prepare for executive meetings
    There is nothing more annoying to executives than to attend project steering meetings and discover that the content is not thoroughly prepared or well researched. Poor content means that executives will be turned off, vital decisions will get delayed and projects will not move forward. Additionally, when issues are discussed it is always helpful to show the root causes accompanied by several solutions. All of this helps executives arrive at decisions swiftly thereby minimising the need to have lengthy meetings to clarify the content and explore solutions from first principles.

  4. Always assume executives need to be educated on project management
    Project managers and their teams make the mistake of assuming that executives are fully conversant with the discipline of project management and are aware of the latest trends such as adaptive project management. Nothing could be further from the truth. Executives need to be constantly educated about sound project management concepts, tools and techniques. For instance complex projects require a slightly different approach to conventional projects. Executives will to understand the importance techniques like tracking known unknowns or the rolling wave plan.

    Where appropriate, executives should undergo professional training to enable them to speak and understand the same language as their project teams. Training could be in the form of industry professional project management courses such as PMP or PRINCE2, or customised in house courses specifically design to instil project management concepts within the operating environment of the company. Project managers should exploit every opportunity to encourage executives to learn more about project management. Strong persistence in this matter will eventually pay off.

These are just some of the points that I believe will help both executives and project teams improve executive sponsorship. In the end, executive sponsorship is a two way process that requires strong participations from both executives as well as project teams. This is a long journey and there are no easy short cuts.

Don’t forget to leave your comments below.

Benefits Management – the Key to Success in Project Management

Written by Andy Trainer on . Posted in Articles. 9 Comments on Benefits Management – the Key to Success in Project Management

As mentioned on the official APMG description of PRINCE2, one of the things that makes PRINCE2 stand out from other project management methodologies is the focus on continuous improvement and the importance of the viability of a project – the project lifecycle doesn’t stop when the product is delivered.

Benefits should be included in the business case of a PRINCE2 project, but are often a tricky factor to define and manage. The reason for their importance is because, although the project is undertaken to produce a product, what the business actually wants is the benefit of that product. E.g. if it’s a new product for sale, the benefits are the sales from the product. If the project is to develop a new content management system, that system needs to make the business more efficient and therefore save money.

Documenting clearly defined benefits can also help ensure buy-in from everyone working on the project – team members’ doubt in its value can be damaging.

It’s crucial that a project manager questions the customer on the benefits they expect once the product is delivered, and moving forward from there. Delivering a successful project blind to expected benefits could mean miscommunication and, ultimately, undeserved damage to the project manager’s reputation in the eyes of the customer.

Consider this story, we’ve all heard similar tales but this one in particular was relayed to me by one of the delegates on our PRINCE2 training course just last week. They had been asked to manage a project developing a new CMS and were given very specific requirements for how they’d like it to work. The project manager delivers this product as specified – but it transpires that the new system is harder for the users to manage which means none of the assumed benefits are achieved. The customer blames the product and, by association, the PM.

Now, this individual came on our course for all the right reasons – they realised that working under a specific project management framework would mean that issues like this could be avoided. But it got me thinking about benefits and the responsibility of the PM to manage these. In essence, benefits realisation management is about outcomes as opposed to outputs.

How to Realise and Manage Benefits in PRINCE2

A useful way of helping the Customer or Senior User to identify expected benefits is by using the 5 Whys method of root cause analysis, a technique used in Lean Six Sigma. Asking the Customer what they want (a new product), why (they don’t sell this but others do), why (if other people sell it, it must be in demand) why etc.

Usually, the Senior User will specify and defend the benefits – this will form the basis of the business case. They will be in line with the business’s high-level strategic objectives, and any benefits management done as part of programme management where relevant. The inclusion of the end user in the PRINCE2 process is another key to its beauty and popularity.

In PRINCE2, the Benefits Review Plan is put together by the Project Manager in the initiation stage of the project. This will document the following:

  • The expected benefits as outlined in the Business Case
  • How these will be measured objectively – and against which base line value from before the project was initiated
  • Who will measure the benefits (usually the Senior User)
  • When they must be measured (sometimes some benefits will be achieved while the project is still ongoing) The Project Board must agree on how far along the line the benefits will be measured once the product has been delivered.
  • Tolerances
  • Dependencies
  • Disbenefits

Once created, the Benefits Review Plan will be submitted and approved by the Project Board. It is revised at the end of each stage within the project, usually with separate benefits for each stage of the project.

During the final benefits review, the Senior User will identify and evidence benefits that have been gained.

Dis-benefits

It’s a clumsy term but is used in the PRINCE2 manual to describe how benefits must always be managed alongside expected negative outcomes. For example, perhaps the new CMS will run much more quickly but require more maintenance. A very common dis-benefit is a reduction in productivity during the time taken for users to learn to use a new software product.

Dis-benefits are not the same as risks. Risks are outcomes that might occur, and dis-benefits are outcomes that have been identified and accepted as very likely or certain consequences of the project and its product. Of course, dis-benefits should be analysed to ensure they will not outweigh the benefits!

Dependencies

Benefits of a product will always depend on more than just the delivery of the product by the project. The benefits will depend on such things as effective implementation of this product, which may or may not fall within the project remit.

Dependencies are very important when it comes to identifying where the line of responsibility is drawn. Other individuals or organisations are often dependencies, e.g. the supplier providing the right goods at the right time, or appropriate trainers being available if the project is delivering a new piece of software.

Why Benefit Management is the Key to Project Management

No matter how closely you follow the rest of a project management methodology such as PRINCE2, if the ultimate goal is misguided then it will be hard for anybody to consider the project a success.

Project Managers need to be remembered and reemployed for delivering results, not just products, so it makes sense for responsibility for benefit realisation and management to fall within their hands.

Don’t forget to leave your comments below.