By Kevin Korterud
As both a project and program manager, I’m always keen to have projects and programs take the right first steps toward success. In the past, this would involve selecting the unified delivery approach used for all of the projects on a program. The idea was to impart consistency to the way projects were managed as well as produce common metrics to indicate progress.
It’s not that easy anymore. Today’s programs have projects with agile, waterfall, supplier, corporate and sometimes regulatory-mandated delivery approaches. In addition, these approaches as well as the different arrangements made with suppliers (e.g., time and materials vs. fixed price with deliverables) have dramatically increased the level of complexity and diversity of delivery approaches within a program.
So as a program manager, how do I keep all of these projects in sync no matter the delivery method? As a project manager, how can I execute my project in concert with the overall program in order to maximize the value that will be delivered, while avoiding schedule and cost overruns resulting from projects not operating in harmony?
These are emerging challenges for which there are no single easy answers, of course. But I have found a handful of tips useful in getting a program’s projects to operate in a synchronized manner. I’ll share the first few in this post and the final ones in my next post, appearing later this week.
1. Remember: There’s No Such Thing as Agile or Waterfall Programs
Given the mix of project delivery approaches, the program needs to properly segment work to manage the budget, resources and schedule regardless of the project delivery approach. In addition, the schedule alignment points, budget forecast process and deliverable linkages need to be identified between the various projects.
Typically, I find that while there is effort to plan for these items at the project level, the upfront effort for this harmonization at the program level is underestimated or sometimes left out altogether—program managers think the project teams will figure this out themselves. This sets the program up for schedule and budget overruns as well as overall dilution of the program business case.
Some ways for a program manager to harmonize projects on a program include:
2. Make the Correct Delivery Approach Choice Before a Project Begins
The type of delivery approach for a project is determined by the type of work being performed and the end consumer of the project’s deliverable.
For example, a project on a program that is slated to create a consumer portal would be a desirable candidate for an agile delivery method. Another project that involves heavy system integration that a consumer never sees would be a candidate for a waterfall approach. A project to pass data into a government system would likely have its delivery approach set by the governmental body.
So before a project starts, program and project managers should agree on the optimal delivery approach that is the best fit for the project.
Look for more advice in my next post on synchronizing a program’s projects, regardless of delivery method.
By Jen Skrabak, PMP, PfMP
Fifteen years ago, I transitioned from being an IT manager to a project manager for the first time. With this month’s theme at projectmanagement.com being “new practitioner PM,” here are three key lessons I learned while managing my first projects.
When I was an IT manager, I always had projects that were assigned to my department. I loved being part of large projects so much I realized I wanted to do it full-time. So I made a conscious decision to transition to being a dedicated project manager.
Managing a project is truly like being a CEO of your own company—you have authority over budget, resource and key decision-making responsibilities. However, it’s an art, and mastery takes time. These are the three fundamental lessons I learned:
1) Communication is about simplifying and personalizing.
Although we may hear that 90 percent of a project manager’s job is to communicate, the best communication is one that doesn’t contain acronyms, special terminology or techno-speak.
Remember that key stakeholders are often involved in multiple projects. To get their attention, you need to make your communications concise and personal while clearly specifying the action desired.
Avoid lengthy mass emails, and tailor the frequency and channel according to the person. One sponsor told me she gets so many emails that I should schedule a meeting if it’s important. Another sponsor told me he works best with instant messaging if I needed something immediately.
The key is to know your audience and adapt accordingly. My first sponsor meeting always includes finding out how and when he or she would like to be communicated with.
2) Project management is about knowing which tools to use when.
Yes, project management is about processes, knowledge areas and ITTOs (inputs, tools and techniques, outputs), according to the PMBOK Guide. But, most importantly, it’s a menu of available options.
Trying to do everything by the book or insisting on adherence to every single template and tool is setting yourself up for disaster. Assess the needs of the project, and don’t ignore the culture of the organization. You can’t go from zero processes to textbook processes overnight. You may need to start slow by introducing concepts and build from there.
3) Build relationships.
Trust is key. When you’re starting out as a project manager, you’re an unknown, so you need to work extra hard to establish the relationships. It’s important to come across as professional, yet approachable and flexible in order to build confidence with your team, and most importantly, your sponsors and key stakeholders. Regular, relaxed one-on-one meetings, such as getting coffee or grabbing lunch, help to build cohesive partnerships that will pay dividends when the going gets tough on the project.
By Lynda Bourne
Organizational agility is being promoted as the silver bullet to create value and eliminate project failures. However, decades of research show that factors like methodologies and standard operating procedures (SOPs) are essential underpinnings of consistent success.
Are these mutually exclusive propositions? Or is there a more subtle answer to this apparent contradiction?
First a bit of background: There’s decades of research looking at various maturity models, ranging from the old CMM (now CMMI) to PMI’s OPM3. The consistent findings are that investing in creating organizational maturity demonstrates a strong return on investment. Developing and using a pragmatic methodology suited to the needs of the organization reduces failure, increases value generation, and outcomes become more consistent and predictable. These findings are supported with studies in the quality arena, including Six Sigma, which consistently show that good SOPs reduce undesirable variability and enhance quality.
But given that every methodology consists of a series of SOPs, where’s the room for agile? In fact, you can get the best of both worlds by embedding organizational agility into your procedures, methodologies and management.
Solid Standard Operating Procedures
Getting your standard operating procedures right is a good starting point. SOPs should define and assist project teams in the performance of standard processes. SOPs also should provide templates, guidelines and other elements that make doing the task easier and quicker.
Key success factors for SOPs are:
The enemy of useful SOPs is a dictatorial unit focused on imposing its view of how work should be performed in a bureaucratic and dogmatic way.
Methodologies combine various SOPs and other requirements into a framework focused on achieving project success. A good methodology must also be lean, light and scalable so it is fit for use in different circumstances. Every project undertaken by an organization is by definition unique, therefore the methodology used by the organization must allow appropriate flexibility—one size does not fit all, ever!
The PMBOK® Guide describes it this way: “Good practice does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or the project management team is responsible for determining what is appropriate for any given project.” A good methodology incorporates agility by including processes for scaling and adjusting the methodology to fit each project.
The final element in blending agility with sensible processes is an agile approach to management. But agile doesn’t mean anarchy. It means the flexible application of the right processes to achieve success.
The so-called military doctrine of command and control is outdated. The rigid, process-oriented concept was replaced by the idea of “auftragstaktik,” or directive command, in the Prussian army following its defeat by Napoleon at the battles of Jena and Auerstedt in 1806.
The core concept of auftragstaktik is “bounded initiative.” Provided people within the organization have proper training and the organizational culture is strong, the leader’s role is to clearly outline his/her intentions and rationale. Subordinate personnel can then formulate their own plan of action for the tasks they are allocated and design appropriate responses to achieve the leader’s objectives based on their understanding of the actual situation.
But the process is not random. SOPs define how each specific task should be accomplished, and bounded initiative allows team members to optimize the SOP for the specific circumstances to best support the leader’s overall intent.
Helmuth von Moltke, chief of staff of the Prussian army for 30 years, believed in detailed planning and rigorous preparation. But he also accepted that change was inevitable, famously saying, “No plan of operations extends with any certainty beyond the first contact with the main hostile force.”
Projects are no different! Both the methodology and the project management plan need to encourage bounded agility to lock in opportunities and mitigate problems. Effective military leaders were doing this more than 150 years before the Agile Manifesto was published. It’s time for project management to catch up!
How much bounded initiative does your methodology allow?
By Jen L. Skrabak, PMP, PfMP
Just like portfolio managers, business analysts are gaining wide acceptance as a profession. Business analysts can now earn their own PMI certification (PMI-BA) and read their own practice guide (Business Analysis for Practitioners). (Here’s a piece of cultural trivia: Did you know the latest bachelor on the reality TV show “The Bachelor” is a business analyst?)
Portfolio managers should get to know business analysts in their organization, because they can help ensure alignment and management of the portfolio to achieve the organization’s strategic goals and objectives.
What exactly do business analysts do? They, well, conduct business analysis. That’s defined as:
•identifying business needs
•eliciting, documenting and managing requirements
•recommending relevant solutions
With this in mind, there are four major ways that portfolio managers can leverage a business analyst:
1) Develop Pipeline Opportunities
Business analysts can play a critical role in analyzing business problems and opportunities that will eventually be used to initiate projects and programs in the portfolio. Product or technology roadmaps can outline potential projects or programs that will be initiated at future points. They’re also valuable during a project because they can support proposed changes to a project scope (which will affect the overall portfolio) and ensure that the business justification for the project or program remains valid.
Many business analysts are embedded within business areas and are critical to early identification and understanding of future opportunities or changes to the portfolio.
2) Define Needed Business Capabilities
We often think of business analysts as documenting business requirements. Those requirements are built upon an understanding of which capabilities are needed for a particular business domain.
Typically, capabilities are based on the goals and needs of a particular business area. Those needs may be depicted through business domain capability maps, end-to-end process flows or functional diagrams. An assessment of whether the capabilities currently exist or not becomes the basis for identifying priorities and gaps (in processes or talent). It can also be used to benchmark against other companies.
3) Develop Business Cases
With their high-level understanding of the goals, objectives and needs of the enterprise, business analysts can assist in defining the justification for the proposed solution. The basis of a business case is the needs assessment. This process seeks to understand the underlying business problem, assess the current state and perform a gap analysis against the future state.
In addition, the proposed solution (see #4 below) is needed for high-level cost estimates that become the basis for the numerator of the ROI. The potential return (denominator of the ROI) is also based on an analysis of the impact of the solution on the current process.
4) Perform Solutions Analysis
One type of solution analysis is to assess a variety of options to go from the current state to future state. (For example, process changes vs. system implementations.) Business analysts can work with business stakeholders to define immediate solutions (quick wins that may be process changes) or longer-term solutions (new products or systems).
Business analysis outputs provide the context to requirements analysis and solution identification for a given initiative or for long-term planning. Business analysis is often the starting point for initiating one or more projects or programs within a portfolio. The analysis is an ongoing activity within a portfolio as the business environment changes and more information becomes available, creating new competition and strategies.
How do you work with business analysts? Share your experiences and best practices in a comment below. Also, if you’re looking to learn more about how business analysts can support practitioners, check out this pmi.org webpage.
The 3 Things That Transcend All Project Approaches
Human Aspects of PM,
New to Project Management,
Categories: Agile, Best Practices, Change Management, Communication, Complexity, Facilitation, Generational PM, Government, Human Aspects of PM, Innovation, IT, Leadership, Lessons Learned, Mentoring, New to Project Management, PMOs, Program Management, Project Delivery, Project Failure, Stakeholder, Strategy, Talent Management, Teams
by Dave Wakeman
Recently I had the chance to engage with Microsoft’s social media team about some of the issues I have been covering here. Their team brought up a question you may have asked as well: How do you differentiate between “digital” project management and project management?
It’s an interesting question, because I firmly believe all projects should be delivered within a very similar framework. The framework enables you to make wise decisions and understand the project’s goals and objectives.
I understand that there are many types of project management philosophies: waterfall, agile, etc. Each of these methods has pros and cons. Of course, you should use the method you are most comfortable with and that gives you the greatest likelihood of success.
But regardless of which project management approach you employ, there are three things all practitioners should remember at the outset of every project to move forward with confidence.
Every project needs a clear objective. Even if you aren’t 100-percent certain what the “completed” project is going to look like, you can still have an idea of what you want the project’s initial iteration to achieve. This allows you to begin work with a direction and not just a group of tasks.
So, even if you only have one potential outcome you want to achieve, starting there is better than just saying, “Let’s do these activities and hope something comes out of it.”
Frameworks enable valuable conversations. I love talking about decision-making frameworks for both organizations and teams. They’re valuable not because they limit thought processes, but because they enable you to make decisions based on what you’re attempting to achieve.
Instead of looking at the framework as a checklist, think of it as a conversation you’re having with your project and your team. This conversation enables you to keep moving your project toward its goal.
During the execution phase, it can give you the chance to check the deliverable against your original goals and the current state of the project within the organization. Just never allow the framework to put you in a position where you feel like you absolutely have to do something that doesn’t make sense.
Strong communication is the bedrock. To go back to the question from Microsoft’s social media team about digital vs. regular project management: the key concept isn’t the field or areas that a project takes place in.
No matter what kind of project you’re working on and in which sector you’re in, the critical skill for project success is your ability to communicate effectively with all the project stakeholders.
This skill transcends any specific industry. As many of us have learned, it may constitute about 90 percent of a project manager’s job. You can put this into practice in any project by taking a moment to write down your key stakeholders and the information you need to get across to them. Then put time in your calendar to help make sure you are effective in delivering your communications.
In the end, I don’t think there should be much differentiation between “digital” projects or any other kind of projects. All projects benefit from having a set of goals and ideas that guide them. By trying to distinguish between different project classifications, we lose sight of the real key to success in project management: teamwork and communication.
What do you think?
By the way, I've started a brand new weekly newsletter that focuses on strategy, value, and performance. Make sure you never miss it! Sign up here or send me an email at firstname.lastname@example.org!