Are You an Effective Leader?

Edgewater ConsultingI’m a bit of a history buff and I recently finished reading Jeff Shaara’s new book “The Smoke at Dawn” which focuses on the Civil War battle for Chattanooga.

The book has me thinking about what makes an effective leader. At the beginning of the novel, one general has every advantage, but focuses on the wrong things. While the other general begins at a major disadvantage, focuses on the right things, and ends up winning the battle.

The novel reinforced some core leadership principles that were good reminders for me.

  • First and foremost – where you decide to focus your energy matters. You can allow your attention to be distracted and squandered on the petty minutia or you can keep yourself focused on key goals. An effective leader doesn’t ignore the details, but does know what is important and what is not. An effective leader actively chooses to spend most of his or her energy on what is important.
  • Second, you need to identify a goal to be accomplished and share that vision. An effective leader ensures that everyone on the team understands what the goal is, why the goal is important, and the part they play in making the goal a reality. Even the “reserve forces” play an important role, and they need to be told what it is.
  • Third, you need to listen to and trust the people in the trenches. An effective leader listens to the team’s problems and removes roadblocks. He or she also listens to their ideas and lets them experiment with different ways to reach the goal.
  • Fourth, you need to recognize and acknowledge the efforts of the team, even when they don’t succeed. An effective leader holds people accountable, but also helps them learn from mistakes.
  • Finally, you need to recognize, acknowledge, and act to correct your own mis-steps.

So in brief, the refresher leadership course I gained from reading a novel. It seems that others have found similar inspiration:   http://blogs.hbr.org/2014/07/what-made-a-great-leader-in-1776/  http://theweek.com/article/index/259151/lessons-from-lincoln-5-leadership-tips-history-and-science-agree-on

So — What leadership lessons have you drawn from unexpected sources?

 

Avoiding Agile Anarchy

Agile project management

Conventional Agile Methodology Wisdom lists three factors that define an Agile-ready project:

  1. High Uniqueness
  2. High Complexity
  3. Aggressive Deadlines

After using these three parameters to select your first agile project, there is still legwork to be done before sprints are humming along.

Many agile initiatives are announced by fiat with the team structure, sprint length and other basic rules of the road mandated by the Agile Initiative Sponsor. They dive right into development sprints, gathering user stories along the way to build a backlog. Here are some ways this approach could backfire:

  • In a rigid, hierarchical organization, the ability of teams to self-organize is often historically non-existent, and the change management hurdle might be a gap too big to jump. There are many ways that interoffice personalities and politics can sink an agile initiative in its early stages, or at any point along the way.
  • Complex, unique projects require some upfront work on architecture before the development sprints can begin. Agile teams can best manage this by making the first few sprints architecture sprints. Time and again, we have seen horror stories when the overall design or architecture is glossed over:
    • Parallel agile teams within a business design disparate UI’s to enable functionality that is essentially the same, but serves the needs of one particular product group. Before long, it’s obvious that external stakeholders are confused and put off by having to remember two different ways of interacting with the same company
    • User stories are taken down as the basis for development sprints, but they fail to consider the secondary stakeholders. BI reporting needs are often missed.
    • Prioritization of the backlog is driven by business need, without any attention to building foundational pieces first, then layering on transactions.

In short, Agile without Architecture leads to Anarchy, and a lasting bad impression that will taint future Agile efforts. It’s best to look before you leap and take time to address any Agile readiness gaps.

 

PMOs and Business Strategy

cogsFor most organizations, the Project Management Office (PMO) is simply a centralized organizational structure for standardizing practices used in the delivery of their projects.  An effective PMO allows these organizations to more consistently deliver successful projects.

For some high-performing organization, the PMO is able to achieve much more.  It is able to help the organization drive and achieve its business strategy.  So how can something as boring and ordinary as good project management become a key to organizational success?

First, let’s think about the planning process.  Successful organizations define their goals and their plans for meeting those goals using some type of strategic planning process.  As a goal (e.g. achieve 5% organic growth) is refined into a strategy (e.g. by attracting more customers through a better customer experience), strategic and tactical projects emerge (e.g. redesign customer portal to improve ease-of-doing-business).

A mature, fully-engaged PMO becomes the keeper of the project portfolio.  If the PMO understands the strategy that the organization is striving to achieve, the PMO can use this understanding as it manages the project portfolio to drive that strategy.  First, and most critically, the PMO ensures that key, business-critical projects are delivered successfully.  It also ensures that project success is aligned with and measured against the strategic goals that the project is defined to address.  The PMO works with the project teams to define KPIs that clearly tie to the organization’s strategy.  If a project can’t be tied to the strategy, the organization can then determine if the project fits into the portfolio.  Similarly, the PMO can be used to resolve priority conflicts between projects, helping to clarify situations where the strategy may be at odds with itself.

More pro-actively, the PMO can forecast capacity, helping the organization understand how much change it can realistically undertake within a given budget or timeframe.  The PMO can also see and exploit synergies between projects, helping the organization take advantage of unexpected opportunities.  For example, given its view of the project portfolio the PMO may see how a service being built to support one project can be utilized to simplify or enhance another project.  Finally, the PMO provides a feedback loop, informing the organization of its progress against its strategic goals and allowing it to take early, corrective action when progress lags or goals shift.

Thus, a PMO becomes a crucial management tool for implementing the organization’s strategy.  Organizations that are able to effectively use this tool are better able to achieve their organizational goals and thus continue to thrive.  In today’s competitive and challenging environment, can any organization afford not to take full advantage of a PMO?

Do PMOs Matter

successProject Management Offices (PMOs) have become a fixture in many organizations.  According to the 2012 State of the PMO Study, 87% of organizations surveyed have a PMO, up from 47% in 2000.   Although mid-size and large companies are more likely to have a PMO than small companies, the biggest growth, by far, was in small companies – 73% of small firms now have PMOs and over 90% of mid-size and large companies have them.

Still, people question their value and ask, Does having a PMO matter?

The statistics say yes.  According to the 2012 State of the PMO study, PMOs directly contribute to the following performance improvements:  a 25% increase in projects delivered under budget, a 31% increase in customer satisfaction, a 39% improvement in projects aligned with objectives, a 15% cost savings per project, and a 30% decrease in failed projects.

Experience also says yes.  A 2012 PMI White Paper described multiple PMO success stories.  In one case study, a company shifted the focus of its PMO from a process orientation to an outcome orientation. The PMO now focuses on working with organizational units as they launch projects, requiring them to build a business case and complete a scorecard to demonstrate how the project aligns with corporate strategy.  The reorganized PMO was able to triple the number of projects that delivered on organizational strategy.  In another case study, an organization was able to reduce project planning time by 75% through standardizing and leveraging common project plans defined by the PMO.

Having a PMO CAN matter, but simply having a PMO is not a silver bullet.  Implementing an idealized methodology that isn’t tailored to an organization’s needs and cultures won’t suddenly or magically solve all problems.  To meet its objective of improving the likelihood of project success, the PMO must gain maturity and acceptance within the organization.  It must become more than another structure or process.  It must become focused on continuous process improvement and proactive management of the project portfolio.  Keys to achieving this level of maturity are strong executive sponsorship, tailoring the PMO to solve practical, real-world problems within the organization, and actively measuring PMO and project success.

So if you are an organization that struggles to consistently deliver business critical projects do you have a PMO?  If you do, is it as effective as it could be?  Maybe it is time to consider the benefits of a PMO assessment and reap the rewards that a highly functioning PMO can bring to your organization.

Why a PMO

shudder_homer_smallProject Management Office

The words make some shudder.  Of course PMOs have existed for a long timeThey grew as the discipline of project management itself matured and people recognized that project management was a distinct skill set that demanded training and experience, as well as certain natural talents.

While PMOs are often associated with larger firms which need to establish a standard methodology and approach for initiating, managing, and controlling systems-related projects, there are many reasons why a company might consider establishing a PMO.

First, a PMO does not need to be focused on systems-related projects.  The real benefit of a PMO is its ability to bring a disciplined approach to how an organization approaches projects.  Any time an organization is contemplating a series of projects to introduce transformational change, a PMO can improve the odds of success.  Those projects can be systems focused, but they could also be focused on business process redesign, new product development, geographical expansion, acquisition, or reorganization.  Each organization can decide for itself what type of projects should fall under the auspices of a PMO.

Similarly, a PMO does not need to be focused on all aspects of project management – at least in its initial implementation.  A PMO should address existing organizational problems.  If the organization struggles with prioritizing project requests and deciding which projects to fund and staff, the PMO should be focused on this issue.  If the organization struggles with keeping projects on track and resolving issues during project execution, the PMO should be focused on this issue.  Simply implementing a PMO doesn’t bring value to an organization.  Implementing a PMO so that it addresses the real-world issues that the organization is facing does bring value.

While PMOs take many shapes and flavors, they all seek to improve communication, collaboration, and consistency.  Organizations face increasingly complex environments while striving to respond to customer demands.  They often rely on a set of projects to drive the organization towards a new strategic vision of itself.  These organizations can leverage a PMO to more effectively meet these commitments.

So why consider a PMO?  If your organization is facing substantive change and needs to improve its ability to consistently and successfully deliver projects so that it can implement that change, a PMO can help.

A More Agile Approach to Project Management for 2013

project management.jpgIt’s been a while since we’ve done an annual wish list for project management, and while we are a few days into the new work year, it’s not too late to think about some PM rules to live by for 2013.

Fluidity is key; rigidity can stifle project progress. Traditional frameworks call for a priori definitions of roles and responsibilities. In many highly successful organizations, models have been shifting toward more collaborative structures. Efficient teams are being built of all-rounders instead of silo’ed specialists. Such a staffing model provides more opportunity for agile workload balancing over the lifecycle of a project, and may enhance the team’s ability to bring the project in on time.

Managing your stakeholders expectations is more important than managing your project team. Let’s assume you have a skilled team and a well written project plan. Should you be spending most of your time micromanaging and tracking the status of their every move, or would you add more value by communicating more often and more directly with your stakeholders? Let’s stop considering communication a “soft skill” and recognize it as a key enabler of project success.

Change is not a necessary evil. Typically, the project management framework views change requests or change control as a negative, but the level of agility required for most businesses to survive make changes in scope a GOOD thing from a business perspective. Classic project management provides a framework for executing scope changes, and good project managers embrace the change requests, calmly, cordially, and without an attitude of tension or disdain.

Collaboration tools are no substitute for interpersonal interactions with your team or stakeholders. Email alerts, project portals, tablet apps that give visibility into project status are all great tools. but sometimes the best way to stay on top of progress is still to walk around with your issues and tasks lists, cruising by cubes and offices to get status updates in the context of informal conversations. The upside is it allows you to keep a finger on the pulse of the people who are important to your project, and it promotes better engagement. A phone call to remote team members is always appreciated. This is especially important with key executives. Firing off email requests for status is not the hallmark of a good PM.

Less is more. Lean thinking is everywhere these days (and I’m not talking about post holiday diets here). In the entrepreneurial community it’s all about minimum viable product. Agile methodology has pushed projects in the lead direction, with each iteration being a minimum viable release of sorts. In 2013, let’s think about minimal project structure. Rather than adding to a methodology, think more about what we can strip away to do it better, faster, cheaper.

Black-Swan-logo-Revise

Keeping the Black Swan at Bay

A recent article in the Harvard Business Review highlighted some alarming statistics on project failures. IT projects were overrunning their budgets by an average of 27%, but the real shocker was that one in six of these projects was over by 200% on average. They dubbed these epic failures the “black swans” of the project portfolio.

The article ends with some excellent advice on avoiding the black swan phenomenon, but the recommendations focus on two areas:

  • Assessments of the ability of the business to take a big hit
  • Sound project management practices such as breaking big projects down into smaller chunks, developing contingency plans, and embracing reference class forecasting.

We would like to add to this list a set of “big project readiness” tasks that offer additional prevention of your next big IT project becoming a black swan.

Project Management Readiness: If you don’t have seasoned PMs with successful big project experience on your team, you need to fill that staffing gap either permanently or with contract help for the big project. Yes, you need an internal PM even if the software vendor has their own PM.

Data Readiness:  Address your data quality issues now, and establish data ownership and data governance before you undertake the big project.

Process/organization/change management readiness: Are your current business processes well documented? Is the process scope of the big project defined correctly? Are process owners clearly identified?  Do you have the skills and framework for defining how the software may change your business processes, organization structure and headcounts? If not, you run a significant risk of failing to achieve anticipated ROI for this project. Do you have a robust corporate communication framework? Do you have the resources, skills and experience to develop and run training programs in house?

Let’s face it: experience matters. If you’re already struggling to recover from a technology black swan, you are at considerable risk for reproducing the same level of failure if you don’t undertake a radical overhaul of your approach by identifying and addressing every significant weakness in the areas noted above.

We have developed a project readiness assessment model that can help you understand your risks and develop an action plan for addressing them before you undertake anything as mission critical as an ERP replacement, CRM implementation,  legacy modernization or other mission critical technology project. If you have a big project on your radar (or already underway), contact makewaves@edgewater.com to schedule a pre-implementation readiness assessment.

How does your company handle major change?

Although many large technology initiatives fail because an inadequate or inefficient change management framework, many companies still lack a consistent approach in supporting their employees and external stakeholders through major system implementations and other significant business initiatives.

 

 

There are many reasons for this.

  • The roles and responsibilities for communication, training, and monitoring performance remain vague.
  • The approach varies from department to department.
  • Information is pushed out once in the wrong format (usually by email) and not made available on a portal under version control. We see this often in companies that have an immature or outdated collaboration style.

We’ve put together a short poll on change management approaches. Please take a moment to tell us how your organization handles major change, and share your thoughts in the comments.

Project Management for Policy Administration System Replacements: Art or Science

As anyone can tell you, project management is a key cornerstone to the successful completion of any project, but for extraordinary projects, like Policy Administration System Replacement projects, a more sophisticated level of project management is needed. But what does a more sophisticated level project management look like? The myriad of project management disciplines and methodologies out there can give the impression that complex projects require a project management approach that is more scientific and systematic, when in actuality, the more complex the project the less systematic project management gets. This is a counter-intuitive notion, since one would naturally think the more complex the project (i.e., Policy Administration System Replacement project) the greater the need for a systematic project management approach to make sure nothing is missed. This is not to say the project management disciplines and methodologies out there offer no value on a Policy Administration System Replacement project, because they most certainly do.  However, when managing a Policy Administration System Replacement a project manager should always keep in mind that those methodologies and tools are merely a starting point (i.e. the “canvas”) for that masterpiece that is successfully managing an endeavor of significant size and complexity in practice.

When practicing the art of project management, there are a number of tactics that should be adhered to, particularly on a Policy Administration System Replacement project, which you are not going to find in the PMBOK. These tactics are not hard-and-fast rules in terms of execution, but are more fluid. What do I mean?  Well let me provide 4 examples of what I mean:

  1. Don’t Fall into the Form-Over-Substance Trap – I have seen project managers that can pull together very detailed and comprehensive project plans, create one hell of a status report, capture every risk and issue on a log, and follow whatever management methodology selected for a project to the tee and yet the project fails. In the project postmortem, there are many reasons for a project failure, but in my experience the majority comes down to management. Adherence to project management dogma over substance is a project killer and focusing too much on the paper work rather than results of what really matters does no one any good. Bottom-Line: Use project management methodology and tools as a starting point only and never mistake project administration for project management, because they are not the same thing. So not only should managers not be afraid to deviate from methodology, if they can see how it could provide additional value to the project team and/or the client, a manager should look for opportunities to do so since staying on the strait-and-narrow will bread rigidity that will ultimately doom the project when it does come time to decisively change direction. The art of this approach is in the notion that managers need to know when to let, that which truly does not matter, go when there is a need to focus on critical issues. Reschedule/skip that regularly scheduled meeting, don’t obsess about missing that status report submittal, if the project plan doesn’t get update for a few days that is ok.  Those things are not project management; project management is about knowing when those things don’t matter in light of the overall project goals.
  2. Pay Attention to Your Instinct –  Missing a due date on a project plan, having an identified risk go into red status, being alarmed by the number of bugs being logged  on a just release build of the system code; these are not the primary indicators that there is a project issue. A project manager on a Policy Administration System Replacement project should intuitively know about these issues well before those types of indicators manifest themselves in the normal project management documentation.  It is counter to the way many talk about/view project management, but in Policy Administration System Replacement projects, project managers need to place just as much reliance on the gut than the head in many situations given that they almost never have all the detailed information at hand.  If a project manager is blind-sided by any of these happenings (and yes it will happened at least once on the project), then chances are the project manager is discounting the intuition side of the equation.  If it doesn’t feel right then it is probably not right. Trust that feeling on a Policy Administration System Replacement project and start to take action. In all likelihood it could end up saving the project.
  3. Get On A One-On-One Level – Policy Administration System Replacement projects are large undertakings, involving many people from across locations, organizations, departments, and disciplines; not to mention walks of life. Often it is tough, if not a practical impossibility, to meet all team members face-to-face or talk one-on-one at least once, let alone regularly.  And the advice that, even despite these typically challenges, the project manager should try to meet all the all team members face-to-face or talk one-on-one at least once during the project is not revolutionary, but what I am trying to get at here is that there is another level that needs to be reached. To manage a Policy Administration System Replacement project the “one-on-one talk” is a key strategy for successful project management. The one-on-one conversation is where managers can get key pieces of information, but it is not something best achieved in an overly procedural manner. Picking out a few key people on the project t and scheduling a recurring one-on-one conference call will not do. With that approach it will not take long for the feedback to become obligatory and stale. Sometimes you get your best results when the person does not know when the project manager is going to call to get a status or inquire about their feelings on how the project is going. Also the “key people” you need to talk to are not always the people in the key project roles. A project manager on a Policy Administration System Replacement project will need to figure out who and when to call; that is the art of the process. The one-on-one conversation should be informal, but these types of discussion should be a common occurrence regardless of project status or stage. The one-on-one conversations a manager has on the Policy Administration System Replacement is often more important than the regularly schedule status and team meetings that are a staple of all projects (big and small).
  4. Listen More Then You Talk At Status Meetings – On a Policy Administration System Replacement project it is a practical impossibility for the project manager to read every email, be up-to-speed on what everyone is working on and the status of the applicable tasks all the time, which is why the art of listening gets a special place in the management of a Policy Administration System Replacement project.  And I don’t necessarily mean listen to the specifics of each team member report, because, while the technical/operational details of a report is of course important, how a team member gives their report is often more important. You can get technical status details in an email, but you can’t get other details that are perhaps more telling, like: body language, pauses, voice inflections, etc. These tell-tale-signs indicate whether a team member really knows what their assignment is, how it is progressing, are they disengaged from the project, etc.  This information will help the project manager determine who he/she needs to follow up with outside the team meeting and who is on track and therefore need less oversight in the short-term. If managers ignore this type of involuntary feedback, they could miss personnel/ operational task issues that could result in level project issues if not address.

There are of course more non-traditional tactics employed in the management of a Policy Administration System Replacement project, but the main point is to try to shift the thinking that the key successful project management of a Policy Administration System Replacement is a greater adherence to methodology and tools. Project management is an art as well as a science and the Policy Administration System Replacement project requires at least an equal measure of both to be successful.

Ten Ways to Ensure Project Failure

Sometime ago I read an article about the top ten ways to destroy the earth. Although it is a bit morbid to even think about such a topic let alone compile a top ten list, it certainly is an interesting scientific problem. Blowplanet_collide0ing planet earth to bits is not as simple as it may seem. It takes considerable amount of energy to blow up six sextillion tons of rock and metal. However, there are some exotic ways to get the job done. From creating a micro black-hole on the surface of the earth to creating an anti-matter bomb with 2.5 trillion tons of anti-matter to creating perfect Von Neumann machines (self-replicating), they are all pretty futuristic and not part of our everyday experience. Some may say- “why even think about such an absurd subject?”, but it does have few practical applications. If nothing else, it helps us think about possible dangers to the only known planet capable of supporting life.

While blowing up earth may for now be out of our grasp and may require giant leaps in technology, blowing up an IT project is quite easy. I can say that with authority, because I have seen many projects self-destruct right in front of my eyes and at times I may have contributed to some of them. So here are the ten ways of blowing up an IT project:

  1. The Missing Matter—Requirements: Lack of business and functional requirements or requirements lacking appropriate level of detail.
  2. Progress Black Hole: Lack of mechanisms to measure progress, milestones, and deadlines.
  3. Caught in the Gravitational Pull of Technology: Focus on technology itself rather than achieving business objectives through technology.
  4. Supernova – Out of Resources: Unrealistic expectations and deadlines – trying to achieve too much in too little time and with too few resources.success_failure1
  5. Consumed by Nebulous Clouds: Constantly changing requirements and feature creep. Inability to give the project and product a solid shape and direction. Lack of proper change control process.
  6. Bombarded by Asteroids: Loss of focus and progress due to multi-tasking on unnecessary side projects and other distractions.
  7. Lost in Space: Lack of a well defined project plan with appropriate level of details, milestones, and resource allocations.
  8. Too many WIMPS (Weakly Interacting Massive Particles): Lack of interaction with the business users, lack of sufficient number of check points, lack of business user involvement during the planning, build, and deployment phases.
  9. Journey to the Edge of the Universe: Attempting to run a project with bleeding edge technology, inexperienced project team, and poorly understood business objectives.
  10. Starless Solar System: Lack of clear and convincing business case and mapping of how the project will help to achieve the business objectives.