Tag: Plan

Pilot an Agile Project in Your Organization

Written by Evgen Domch on March 20, 2017. Posted in Articles. 3 Comments on Pilot an Agile Project in Your Organization

As Agile is more suitable for software development, but not all companies are ready to move from Waterfall to Agile.

Waterfall has served many projects well and is still considered as a good methodology. It is used by many companies in their day to day work. Agile is a relatively new methodology in development with many advantages, but it is not always suitable for all project types.

Let’s elaborate an approach to starting an Agile Pilot project in your organization.

Select a Project

There are several important factors to consider when selecting a project:

Project size must be at least 4 weeks. This time is optimal to form a full feedback and understanding of the methodology itself. The optimal maximum size of the project is 12 weeks.
The project should be important, but not critical. Since this is a pilot project, it is very important to consider a project without mission-critical deliverables or outcomes with a clear and specific expectation of project success.
Stakeholder involvement is important to involve in the project the Project Manager, designers, developers, testers, and Business Analysts. Ensure feedback from all participants is elicited and documented.
The project selected should go through all stages of development such as initiation, discovery, concept, design, analysis, development, testing and implementation. This gives participants a broader perspective of how Agile works from the beginning of the project to the end of a project.

Chose a Team

Perhaps this is the 2nd most important element in the first project experience is team member selection. Team members should have the skill sets and experience to be able to deliver the project outcomes and deliverables. Beginner or novice team members will have little knowledge of the potential solution will be a detriment to completing the project successfully for the first time in an Agile environment.

The team should want and be willing to implement a project using the Agile framework. Enthusiastic teams are more likely to be successful in implementing an Agile project for the first time.

Team members should also have a basic understanding of the Agile and Scrum methodologies or have used Agile and Scrum methodologies in a previous organization or role. Be careful to have a majority of team members with real experience with Agile on the pilot project. They will be able to help less experienced team members on how Agile and Scrum operates.

Formation of Roles

The next step will be the formation of the roles in the team. Key roles for an Agile team are:

Product Owner
Scrum Master or Agile PM
Development Team
Business Analyst or Customer

These roles are divided into 2 groups. Client Side and Technical. The client side, namely the Product Owner and the BA, are responsible for the creation of requirements and form them into user stories. The goal of Product Owner is to provide “Just enough” information to the development team so that they would be able to begin work on the product within the sprint.

User Stories and Acceptance Criteria

An early stage of planning is “Road Map” or sprint planning. It is necessary to plan each sprint based on the estimates provided on what it would take to complete the user stories. Since this is the first Agile project — accuracy is not what you should emphasize. Be mindful that you are still constrained by the length of the sprint. Your first few sprints will most likely have very inaccurate estimates for user stories. This will result in the first few sprints not accomplishing all the user stories expected.

Planning consists of taking the desired functionality and creating user stories to support them. Each of the user stories should have a specific set of acceptance criteria. This ensures the definition of “done” is clear to the team.

A user story is an instrument of functional description which is typically stated in the following fashion:

As a _________ I want to _________ So that_______

Acceptance criteria describes specific functional requirements that will be accepted by the business for the user story. and show specific steps to achieve the result. Acceptance criteria are typically constructed in this manner:

Scenario: Login

Given: I am on the Log in page, and the login ID and password fields are displayed
When: I am able to enter my login id and password
Then: the login button is displayed and available for me to click to start the login process

Prioritization of User Stories

Prioritization of user stories is an important part of any Agile project. As sprints are very time constrained and this is a pilot program expectations need to be set that not all user stories may be able to be delivered within the expected timelines. Prioritization of user stories will allow those user stories with the most business value to be worked upon first. Sprint 0 planning should take the prioritization into consideration when planning which user stories are placed in specific sprints.

Estimating User Stories and Acceptance Criteria

Once the user stories and acceptance criteria are created, then we are ready to estimate. Typically a T-Shirt size system of XS (extra small), S (small), M (medium), L (large), and XL (extra large). Each user story and acceptance criteria are estimated using this approach. As a pilot project, you will encounter estimates that are not very accurate. This will result in the early sprints of an Agile pilot project to not deliver all the expected user stories for a sprint.

Once the user stories and acceptance criteria are sized, they are slotted into sprints. This activity occurs in Sprint 0.

Getting to Zero

Sprint Zero is a very important event. In this sprint several things will be determined:

Sprint size is determined. Sprint size is the duration of all sprints in the pilot Agile project. All sprints should be of equal duration. Be aware that as a pilot Agile project your durations may be a little longer (such as 3 weeks) in order to assist in team members in learning the Agile process more fully). Typically sprint durations can range from 2 weeks to a month. Pick a duration that makes sense for the team and will result in incremental deliverables that will give the team a sense of success.

Plan each sprint by aligning each user story and acceptance criteria into a specific release based on its priority. Be careful not to overfill a sprint. Realistically align user stories with sprints based on their estimates. As always beware your estimates may not be very accurate. Start the first couple of sprints with a smaller amount of user stories to give your team the time to learn the Agile approach to development.

Once user stories are assigned to sprints, review the tasks needed to complete each user story to ensure the tasks can be completed in the sprint. Be aware that some task may require the efforts of resources that are outside of your team. Where ever possible ensure the tasks that are performed outside of the team are completed prior to the sprint starting. An example of this would be a DBA. A database request may take your organization several weeks to complete and implement. Trying to squeeze the database change into the sprint would result in not being able to complete the sprint fully. Instead, have the DBA request completed before the sprint started to developers can focus on the sprint without having to wait for external resources to complete tasks for them.

Starting Up

Schedule the daily stand-ups. Be sure all team members understand the daily standup and the purpose of a stand-up meeting. Put a 15-minute meeting on your team members calendars (hopefully schedule in the same room) every day with each team members covering these topics:

What I did yesterday
What I will do today
Do I have any problems or concerns

The scrum master will lead these meetings. Bring a timer. The is 15 minutes in length and time is of the essence. This is a problem-solving meeting. When problems are identified, immediately ask who needs to be involved in determining a solution for that problem. Then have those individuals tackle finding a solution OUTSIDE of the meeting. The amount of time per team member depends on the team size but typically 2-3 minutes is given to each team member.

Interaction with team members is important. Due to time constraints of the daily stand up and sprint a lot of pressure is put on the new Agile team member. Be sure to give them opportunities to discuss their experience and be available to offer solutions to situations that are encountered.

Acceptable Product

Acceptance criteria were established for each user story. As each user story is completed, the acceptance criteria for that user story should be validated. Make sure the team understands that user stories must be validated by the team by executing the acceptance criteria.

End of the Sprint

A sprint review and demo are conducted at the end of the every sprint. This reviews the user stories that were completed ensures acceptance criteria has been met.

At the end of every sprint is a retrospective to reveal lessons learned. This is important as this pilot Agile project will need feedback to improve future efforts and processes to help the pilot Agile project be more successful over time. An hour meeting with all teams should answer the following questions:

What did not go so well?
What still puzzles or doesn’t make sense to us?
What went well? What things should the team keep doing?

A good thing to keep in mind is ending this meeting a positive light. Focus on things that didn’t go well and move into things that went well. This leaves the team members with a positive impression at the end of the meeting.

The leader for the Agile project pilot will need to take steps to improve areas where things didn’t go well or areas that don’t make sense to the team. Always ensure follow-up is performed with the team on items brought forward that need improvement.

Do not try to solve the problems identified in the retrospective meeting. Assign teams members to investigate and get back to the group at a later date.

In a Nutshell

This article elaborates a very high-level set of tasks for piloting an Agile project. The structure and readiness of your organization’s leadership to use the Agile methodology should be explored deeply before starting an Agile pilot project. In setting senior leaders expectations, it is important that senior leaders have a complete understanding of how the Agile Mythology operates. Setting the expectations of senior leaders for the pilot is critical to ensure it has a good chance of success.

Good luck on your Agile pilot project!

Project Failure: A Catalyst for Success

Written by John McGrath on January 30, 2017. Posted in Articles. 5 Comments on Project Failure: A Catalyst for Success

There have been huge advances in project management in the last 20 years, but the elephant in the room is the issue of Project Failure.

Success rates are not improving and the metrics surrounding project failure have been disturbing for decades — at least 50% of projects do not deliver on their promised results.

These failures can cost hundreds of thousands of dollars – and into the millions – for very large projects. Also the lack of program management can cost companies millions of dollars in cost deviation. This is important because, over time, the value of your corporate brand and enterprise success rate are related.

The causes of project failure are well known, predictable and have not changed over several decades. Projects and organizations continue to be impacted and do not seem to be able to create the environment in which projects can succeed. It would seem that organizations have a fundamental inability to learn the lessons of project failure.

There are many causes of project failure and every failed project will have its set of issues. Sometimes it is a single trigger event that leads to failure, but more often than not, it is a complex entwined set of problems that combine and collectively result in failure.

This inability to learn from project failure is across all industries and sectors and includes many of the most successful organizations on the planet. The financials of failure are staggering and a complete industry has emerged to address the reasons for failure, which are as predictable as the next dawn.

We also often realize with the benefit of hindsight that most failed projects were exhibiting early warning signs and there was sufficient opportunity to respond but the signs were not acted upon in a timely fashion.

The definition of success or failure is not as straightforward as was once imagined. We are now very aware that project success cannot be adequately defined within standard parameters: completion within time, cost and performance expectations.

Cost and schedule performance are still important but the perception of project success now also includes:

Meeting the functional or technical specification
Meeting the business case
Engaging with stakeholders

Failure is not comfortable to embrace but it can often be a catalyst for success, especially if project failure comes early in product development and is accepted by all involved as a way forward.

Research shows that about 50% of projects fail because of the lack of visibility over the entire spectrum of the project management process. Take, for example, software development or the creation of a new medical device. Management of the project may involve numerous teams, each dedicated to a certain aspect of the process. However, they are operating in silos, each with its operational style and strategy for success. If these teams do not communicate effectively, the result is often a failure to deliver a successful product, often due to cost overruns or relevance to the target market.

Why Projects Fail

When projects fail, hindsight often reveals that issues were bubbling up – but ignored. These issues may include a lack of hands-on project sponsorship, team leadership, lack of resources, inability to manage change, and lack of communication. Lack of communication is the basic culprit because, without communication among project teams and leaders, there’s no clear visibility into the development process and thus what we call no “single version of the truth.”

However, when a failure occurs early in the project lifecycle, it is because of clear communication among project teams, leading to that single vision of truth. Early failure triggers positive change management and the revamping of strategies, providing a window to a successful result before massive dollars and precious resources are needlessly spent.

Effective execution needs effective planning, which includes not only tools but most importantly, human interaction. This is the art and science of project management – tools and people skills that give total visibility to the entire process.

Developing Hybrid Methodologies and Organizational Procedures

Often organizations think they can just apply off the shelf methodology – lean, six sigma, agile – and just simply apply them to the organization. While these are all good standard practice methodologies, by recognizing the relevance of each and applying them to internal procedures and the organizational toolbox, these ‘good’ methodologies become best practices – and thus a hybrid approach.

There is no magic wand for good practice project management. It takes consistent effort, applying lessons learned from other organizations or international best practices. It takes the entire team – from the C-Suite right down to the project level – to drive success. Everyone must be involved.

Project governance needs senior management support and they must understand the basic tenets of project management and the specific role that they play in the strategy. This group becomes particularly important when change management is necessary. Change rarely occurs horizontally but must come from the executive board, which often gives the go-ahead to drive that change to all project teams. It is important, therefore for the executive team to get on board with the project management scenario at the earliest stages and meet regularly with the teams. This provides the harmony and synergies necessary to manage risks, institute necessary strategic changes, and eliminate unshared silos of information.

Creating a Structure for Success

Leading the effort should be an enterprise project and portfolio management approach, which provides structure (including gate reviews and milestones), standards, reporting procedures, training and team management. A Project Management Office (PMO) can be the backbone of a successful project management approach by assuring that project delivery is managed in a controlled way. Its focus is:

Governance – guidance that decisions are made properly – by the right people with the best information, audits or reviews that assure accountability
Transparency – accurate information to support the “single vision of the truth.”
Quality Assurance – eliminating bureaucracy, providing training and mentoring – making it easier for teams to do their jobs.
Eliminating redundancy – creating a knowledge base for templates, best practices and lessons learned.
Reporting – management of documentation, project history, and risk analysis.

While structures may differ depending on the organization, there does need to be a central point of management that fits easily into the organization’s culture, takes into account the resources available and is the guardian of enterprise portfolio management tools. There may be one or more experts in the PMO who supports project managers and their teams with project management software.

This office may also manage a portfolio level dashboard that provides a type of helicopter review of the project as it moves forward. This dashboard plays an essential role in transparency, providing a comprehensive look at the myriad of details that are involved in project success and how each of those areas is moving forward – or not – in seeking achievement of the end strategies.

Setting up a PMO can be a large undertaking and a considerable upfront investment that must eventually prove its worth, which means a thoughtful approach is the best one. Depending on the time available, it may be helpful to begin the process slowly offering key services and building up as necessary to support projects in the pipeline. This is not unlike the approach that is taken in developing projects by phasing in activities to gain buy-in by stakeholders and identification of problems early before they become unmanageable, i.e. embracing failure as a way to move forward with a more successful strategy.

Gaining support from the executive level, as mentioned previously is key, but only one part of the equation. Seeking support from stakeholders is also critical. Clear communication as to the benefits of the office and its tools is a must and can be delivered in team meetings or one-on-one interactions with important influencers. Moreover, if there are stakeholders who do not seem to agree with the way forward, a special effort needs to be made to create a positive attitude for the benefit of the entire team.

Clear processes are essential but the recognition that these processes may change over time in response to new information or direction reveals the need for a focus on change management. Rather than a flurry of changes that users need to absorb on an ad hoc basis, setting up a recurring plan for review of processes and amendments eases transitions and makes for a smoother implementation.

Finally, stakeholders need to be aware of the long-term benefits of the office but it’s also helpful to show immediate benefits of the PMO to the organization. Depending on the complexities of the projects, it may take some time to the assess the full value of the office but there are a few ways to show progress. For example, introducing templates to standardize processes makes it easier for users to report their activities and gain visibility. Gaining buy-in from project managers on software solutions also can help elevate a positive view of the PMO.

Early Failure Builds Success

Early failure builds a pathway to success. However, early failure can only occur if a strong transparent PMO is in place that focuses on leveraging organization tools, dynamics and culture and that recognizes the importance of human interaction. Communication, transparency, and clear direction are key to a successful implementation that’s built on knowledge transfer and pipeline visibility.

About the Authors
John McGrath, PMO Consultant and Project Management Lecturer at Dublin Institute of Technology and Philip Martin, Founder and CEO of Cora Systems

8 Things You Must do Better to Make Better Decisions

Written by Richard Lannon on December 20, 2016. Posted in Articles. 5 Comments on 8 Things You Must do Better to Make Better Decisions

I have been thinking lately about what it takes to make decisions. Just recently I was presented with a situation where some major decisions will need to be made.

Ones that impact changes in business and careers focus and could mean going into a whole new direction. So you have to make the best decision with the information at hand for your organization. From that perspective I think there are eight things you must do to make better decisions.

1. Invest in decision making skills.

This is something that holds true today as it did ten years ago or more. I see this as a foundational skill that people need to learn, practice and apply. There are many approaches or methodologies that can be applied in the decision making process whether you are a traditional organization, project based, a committee environment or driven by the board of directors. Often the fundamentals of decision making are missing. Look at the environment and create an appropriate decision making structure.

2. Create time to think ahead.

Time, time and more time is something we don’t have. It has become a luxury that most people can’t afford. Yet making good decisions requires time to reflect and look at the road ahead. What if you are considering changing careers and decide to go in a whole new direction? This is a big decision. This applies to a business venture also. Change and transformation are difficult to do on a whim, often you are required to think and plan ahead. But don’t over think long term plans as things change around you quickly.

3. Know who you serve.

This is an important point to answer. I know a lot of business leaders and professionals who I am completely confident in their ability to get the job done, to move forward and make things happen. But, they lack an important insight and clarity of who they serve. Decision making is a whole lot easier if you know who you serve whether it is a specific target market, an organization or something else. I think it provides opportunities to make mindful decisions and improve innovation and creativity in solving problems due to clarity and focus. It does not matter if you upset the market because you know who you serve.

4. Question everything, especially the business.

I often get asked how I would approach a specific problem. I am in a meeting and someone sets up a scenario and wants to know my approach. Any good business analyst, trainer or consultant will know the basics; define the problem, evaluation solutions, implement the approved solution, and measure the results. Part of the process is to question the business model. Recently I had this happen in a meeting with an executive director. I was presented with a question and responded but within that response I placed questions to better understand the business model of this organization.

Turns out they are looking for a change and the business model is suspect. It is always good to question, even when answering.

5. We can all think in a straight line.

Straight line or linear thinking is the a, b, c, of decision making. With so many organizations talking about innovation, creativity and being intentional I wonder what’s the point. There are many theories about what approach you should take. I still think the best approach to decision making and initiative integration is a mix between predictive and adaptive planning. These two approaches provide the best of both worlds, and when blended, often provide an organization an approach that works beyond the mere linear.

6. Create a story around decisions.

Life is a story and you write it yourself. With every decision there is a story that comes from people discussions, thinking, making assumptions, determining impact and communicating the decision. Wouldn’t it be great if you could create a decision narrative that is beyond the old boring business report? People want to be part of the decision story that makes a difference thus bridging organization gaps. You should create decision making stories.

7. We are all moving at the speed of a click.

Over decades my career has been part of the professional consulting and service economy which has accelerated at lightning speed in recent years. When I look at the professions’ value stream I think we need to make better decisions around the downstream business environment. Clients no longer just order or buy stuff they engage now in a very different way where it becomes difficult to determine the ROI on business activities. Margins wither as the need to provide valuable free content increases making business decisions a challenge to make. No matter the business you are in, the accelerated service economy is impacting your business.

8. Find a tool, reduce your risk and get costs under control.

The strategic business analyst looks at the past, present and future of a strategic plan and approach and use financial analysis of NPV, IRR and ROI within your business case. But it is important to go further and look at risk with uncertainty analysis. This is something that I learned over time from various economic adjustments (ie: dot com bubble burst, corporate and accounting scandals, subprime mortgages issue, and resource industry collapse) I think uncertainty needs to be determined better. Business intelligence and uncertainty reducing tools can be used to assist in this analysis. My point, the business analyst can play an important part in helping organizations make decisions through embracing uncertainty analysis approaches and tools to help deal effectively with unpredictable times.

Final Thoughts

Big decisions are tough to make, especially when you have invested so much time and effort on your business or focus area. When you work in a space where you are building skills and helping businesses define their future, you start to realize that there are certain truths that exist. One truth, everybody wants to survive and be around a long time. The second truth, that there is always a purpose that needs to be achieved. Third truth, good decisions and core competencies take you a long way to creating a profitable future thus achieving the first two truths.

7 Steps to Financial Approval of Your Project

Written by Shreenath Sreenivas on October 28, 2016. Posted in Articles. 3 Comments on 7 Steps to Financial Approval of Your Project

You’ve been assigned as the project manager for a project that MUST deliver a critical IT system to avoid legal and compliance repercussions.

You’re told “Your next step is to secure financial approval. Since the total internal funding is limited this year, the Executive Board (EB) is scrutinizing several other high priority portfolio projects, and they all heavily compete with your project. So, get this moving quickly!”

What do you do? Where do you go first?

Below are 7 steps to follow to get financial approval of your project.

1. IDENTIFY AND ANALYZE KEY INFLUENCERS AND THEIR NEEDS

Never assume what people’s needs are! Your first step is to promptly identify and reach out to key influencers to gain insights into the organizational climate, business-IT strategy, approval process and investment appraisal factors.

Also, devise a plan of action to deal with each influencer.

This requires a strong implementation of the PCPM methodology that’s described here.

2. STUDY THE ORGANIZATIONAL CLIMATE, BUSINESS-IT STRATEGY & APPROVAL PROCESS

Organizational Climate: To deliver better outcomes in high growth areas of business organizations transform dynamically and rapidly as the world changes around them. They are constantly looking to improve efficiency and efficacy by reaching new levels of functional excellence.

Focus can shift towards increasing revenue or optimizing cost. In such scenarios, internal funding for major, vision-led, wider organizational initiatives may bypass departmental budgets and come direct from the Executive Board.

Watch out for how the organizational climate could influence the EB’s perception of your project alongside these wider initiatives.

Business-IT Strategy: Understand the current business-IT strategy. Be it application development and rationalization, infrastructure, sourcing or Lean IT. In some cases, implementing the solution quickly and within budget is the sole criterion.

Your job does NOT just end at just delivering the system. So, ensure that the system delivered is in line with the business-IT strategy.

Approval Process: Study the approval process well. If this is not well documented, ensure key influencers are in agreement as to this process.

Every missed step in the approval process could cost you time and money – unacceptable if you are entrusted with a constrained project.

3. ANALYZE THE BUSINESS NEED & ALTERNATIVES AND EXPLORE SYNERGIES

Business Need & Alternatives: This is where your business analysis skills will be helpful! Work with the business to clearly understand the business need and direction. If the business need isn’t clear, propose a review to bring clarity to the issue, even if it takes more time!

Explore all alternatives and their qualitative and quantitative benefits.

Sometimes inefficient or non-scalable solutions may already exist and in such cases doing nothing is also an alternative – don’t forget to list this as well!

Cross-Divisional/Portfolio Synergies: A disadvantage in large complex organizations is that divisions work in silos. The advantage, however, is you can likely find divisions doing similar things. Explore cross-divisional synergies and tap into them. There are benefits and risks – but in most cases benefits outweigh risks. For example, you may be unwelcome to onboard another project due to strategic reasons, but you must try if it favors the organizational strategy. PMs are sometimes unaware of what’s going on around them. Reach out to the PMO to learn of the other portfolio projects and programs. You may find synergies within the portfolio itself. Sometimes, it may involve moving funds between projects, re-scoping projects or even their cancellation in order to use funds more effectively for your project.

4. DEVELOP A SOLID BUSINESS CASE & INVESTMENT STORY:

Solid Business Case: Develop a solid business case for top 3 alternatives – including quantitative and qualitative factors.

A common mistake is that project managers showcase what they would like but not what the Executive Board might look for. So ask yourself “What could the Executive Board be looking for to buy-in to my business case?” This may be a tough question to answer, but resolution comes with experience.
WBS, Project Budget & Contingency Reserve: Not having a solid WBS is the biggest problem. Build on one before you estimate your costs and the overall project budget.

Don’t include random contingency reserves in your budget (e.g. as a % of the overall project cost). The EB will have no tolerance for contingency reserves unless they’re an aggregate of concrete cost estimates required to implement risk responses for known risks. So, implement risk management diligently!

Investment Story: Don’t jump into building an investment story before you understand the key investment appraisal factors – some of which are below:

There may be levels of uncertainty regarding the availability of funding. Long-term secured funds will be committed to longer, high-priority programs that showcase positive NPVs. However, legal or compliance projects may or may not always have a positive NPV. However, try to build on one – challenging, isn’t it? Give it a try:

Quantitative:

Payback: Simplest technique.
Net Present Value (NPV) & Internal Rate of Return (IRR): Higher the NPV or IRR, the better.
Accounting Rate of Return (ARR): Higher the ARR, more preferred.
Adjusted Present Value (APV): APV overcomes the shortcomings of NPV and is used for a highly leveraged project.
Total Cost of Ownership (TCO): Lowest TCO offers the best value for money.
Real Option Analysis: Real option analysis considers and values the various options that managers would have while managing their projects in terms of increasing cash in-flow and decreasing cash outflow.

Qualitative:

NPV with Assumptions: Calculate a financial value by applying a series of assumptions. E.g., include assumptions about the numerical impact of increased morale on staff turnover and the estimated costs of recruitment to showcase benefits. Examples of non-financial factors that can be translated to NPV with Assumptions are:

Reduced maintenance costs due to out-of-the-box industry standard solution.
Productivity time savings; no FTE reduction.
Potential to implement future business needs without further investment.
Relationship improvement with suppliers/customers reducing procurement overhead.
Anticipating and dealing with future risks and threats, e.g. protecting intellectual property against potential competition.
Scoring Methods: Compare the subjective value of benefits e.g. degree of coverage of requirements, the fit of offered solutions, etc.

5. DRAFT A FIRM STATEMENT OF WORK (SOW)

Draft firm SOWs encompassing all aspects of the procurement – top things to consider can be found here.

The EB will challenge you to re-negotiate on costs/time. So, negotiate in the first place and present documented evidence of the Initial vs. Negotiated costs/time. Involve sourcing and legal teams at every phase – they’re crucial in supporting you with securing approval.

6. PRE-ALIGN WITH KEY INFLUENCERS:

So, having to prepare and present your case to the Executive Board can make you nervous and cause what I call the “Executive Presentation Syndrome” – similar to stage fright. To overcome this, find out what the EB needs to approve your project.

If you’re unsure:

Don’t hesitate to learn from your colleagues lined up for approval or to those who have had their projects approved already.
Re-align with each influencer on what they expect from you – that will help them approve your project without surprises on the big day.

This is difficult in today’s global virtual world, but again, PCPM will help. Anticipating in addition to learning is half the battle!

The Executive Board would always like to see tangible factors. Failing to deliver tangible benefits can result in you having to go back and forth with the Board in order to make your case stronger.

Every approval cycle involves multiple reviewers and approvers. Communicate with them on when you intend to submit your project so they can make themselves available or deputize someone to approve your project if they are not available.

7. BE VERY WELL PREPARED FOR THE BIG DAY:

Have a Killer Presentation Ready:

So then, are you ready to present your case to the EB? If not, seriously consider requesting them to push back your presentation to a future date. NEVER go into a meeting unprepared – you’ll lose your credibility and reputation!

When you’re ready, here are a few tips that will help you breeze through the approval process.

Prepare a killer “10-20-20” PowerPoint slide that has no more than 10 slides, takes no longer than 20 minutes and has no text less than 20 point font. Remember that a picture speaks a thousand words!

Tips for the big day:

Come early
Prepare a 15-word summary
Put yourself in the audience and present accordingly
Don’t read the slides
Slow down
Listen
Project your voice
“That’s a good question”: If you’re not ready to answer, offer to come back.
Don’t breathe out or use words like “hmm” or “ah”; repeat the question to ensure you’ve heard it right and this will give you time to work your brain to answer
Don’t apologize unnecessarily
Apologize if you’re wrong
Have fun! Sounds impossible, but with a little practice, you can inject your passion into your presentations. Enthusiasm is contagious!

Finally, don’t forget to thank everyone and celebrate your success!

Manage Your Projects in 60 Minutes a Day

Written by Brad Egeland on September 13, 2016. Posted in Articles. 5 Comments on Manage Your Projects in 60 Minutes a Day

60 minutes. There are 24 of these segments in each day. What can I do in 60 minutes each day?

Well, you can watch your favorite one-hour TV show and still have 18 minutes left over if you record it and skip through the commercials. You can order a pizza and pick it up or have it delivered. Apparently, Bruce Springsteen is now doing nearly four-hour concerts on occasion, so you can see a few songs of one of his concert in an hour. But I think you can also manage your projects in an hour. Yes, one hour – each day. Am I crazy? Maybe, but read on.

I’m not one for multi-tasking. I don’t think men are really good at it – it’s how our brains work. So, if you happen to be overseeing say, 5-6 projects at a time, then spend 60 minutes each day on each project. Certainly, if you have a project that really requires it, spend more time. Maybe one is running full steam ahead, and two are not seeing much action at the moment. Spend two hours on the one that needs it and 30 minutes each on the two that are not requiring much attention right now. But, I think you get the picture – basically an hour per project per day should be the goal. Every project needs some daily attention. And what do we do during that 60 minutes of project-specific project management each day? Focus on these general areas and you’ll be covered every day and every week on every project on anything and everything major AND you’ll be initiating the communication to ensure that the little things do not fall through the cracks.

(Note: keep in mind that this is a general list of tasks that need addressed at least weekly, but not all need to be addressed daily. Make sure you hit all of these at some time during the week when you’re spending your 60 minutes managing each project).

Revise and distribute the weekly project schedule. Using information gathered from your project team via email, phone calls and/or a weekly internal project team gathering, you will need to use a good portion of one day’s 60 minute allotment on a detailed revision of the project schedule, including task progresses, resource assignments, new dates, and any additional work that needs to be added to the project. And be sure to ask for feedback – this is your chance to make sure key needed updates haven’t fallen through the cracks and you can be putting the onus on those all-important project stakeholders to take a good look at the schedule and give them another chance to get any updates into you that they haven’t already covered. If you don’t ask for them, you won’t get them.

Create the weekly status reporting to all stakeholders. Every week we need to spend time preparing a formal status report that – along with the revised project schedule – drives a weekly formal status call with the project customer. This activity, done weekly, shouldn’t take too long – especially if you’re spending focused time every day managing each of your assigned projects. From my experience, though, on the larger, more complex projects this will likely take most of one day’s 60 minute allotment. And just as you do with the revised project schedule and distribution – ask for feedback and updates. Make the stakeholders look at it with fresh eyes and put the responsibility in their hands to actually read it and provide you with any missing updates. I find – through this method – that there is at least one missing an update or key piece of information from at least one stakeholder every week.

Take care of any mail/phone calls and face-to-face discussions that need to happen with the customer and project team and other stakeholders. Regular connection – whether there is much to say or not – is great for keeping project team members and the customer engaged and on task. Included in this is weekly meetings that every project of any real size should be having. You can see where your 60 minutes can really start to get consumed through just keeping in contact with everyone. Communication is Job One for the project manager. Period. Nothing is more important to project success.

Check the resource forecast. Every week time must be spent analyzing your current resource needs on each project and ensuring the availability of your resources today, tomorrow and for the remainder of the project. You do not want surprises. Do this regularly and you won’t be surprised.

Revise the project budget with update actuals and re-forecast. Just like resources need to be examined regularly – at least weekly – the budget health needs the same scrutiny. A budget will almost never get out of hand if you’re on top of it regularly with close observation, frequent revision, and regular forecasting and re-forecasting. Flags can go up almost before there is a problem – while corrective action can still be effective. As I always say, a 10% budget overrun is fixable. A 50% budget overrun likely is not. If you are watching the project budget closely and re-forecasting every week – then you’re on top of it. And it will never likely go outside of that acceptable 10% variance range.

Summary / call for input

We often spend most of our days reactively putting out fires on our projects. What if we just stayed ahead of the game as much as possible with good project management focused on each project every day? What if we didn’t let any project go unmanaged for more than 24 hours. I’m not saying we do, but often we are reacting rather than being proactive.

What would go on your weekly/daily list of project management activities to stay on top of for each of your project engagements? Do you think the 60 minute daily project management scenario works? Please share your thoughts.