Tag: Methodologies

The Project Management “Famous Five”

Written by Kiron Bondale on February 12, 2014. Posted in Articles. 7 Comments on The Project Management “Famous Five”

bondale Feb12 Assuming your organization or department has a published project management methodology, chances are that it specifies that at least a few standard artifacts are created and maintained on every project. These artifacts might be standalone documents, or they might exist as a data set within a project management information system.

One of the most valuable pieces of advice in the Guide to the PMBOK (5th edition) is “Good practice” does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project. As such, competent project managers arm themselves with a toolkit of practices to draw upon, and apply them based on the specific needs of a given project, the maturity of the team and organization, and regulatory or compliance requirements.

For example, on projects possessing a significant degree of requirements uncertainty, using iterative and interactive requirements techniques and artifacts which might help to elicit true needs would be beneficial whereas for those projects in which scope and requirements are very clear, traditional methods of requirements gathering would suffice.

Is there such a thing as a minimal list of project artifacts which should be created and maintained regardless of the size, nature or complexity of a project? The benefits in defining such a list is that it would help to eliminate or at least reduce some of the contention which occurs when a project manager has to justify the need for specific practices with a sponsor or other key stakeholder who views such practices as being unnecessary overhead.

Here are five “must have” project management tools along with rationale for selecting these artifacts and the risks in not using them.

Charter – whether this is a single page document or something closer to a high-level plan, the charter is the one tool which a project manager can wield to demonstrate that their project has been formally authorized and, when it is well written, it will help to align key stakeholders and the team towards the project’s expected outcomes. Without an approved charter, it may be challenging for the project manager to engage the resources required to plan and deliver the scope of the project, and there is a greater likelihood of stakeholder misalignment.

Approved plan – agile fanatics might cringe at the necessity for this, but it goes back to the basic criteria which define a project – it is a temporary endeavor consuming resources to deliver unique outputs which will generate business value. In the absence of documentation which clearly states what will be delivered, by when, how, with what resources and for how much, it is likely that the project will either be cancelled prematurely when funding or time runs out, or branded a failure upon completion if customer expectations have not been set and met. Two critical components of this approved plan are objective project completion and project success criteria – without those, the project may turn into a shuffling zombie from the set of the Walking Dead.

Current forecast – it does no good to have an approved plan if you have no idea as to how you are tracking to it. The forecast will cover the same knowledge areas as defined within the approved plan and should be used as the basis for communicating project status. Without this, stakeholders are left to guess how a project is doing, and it will be difficult to detect negative variance trends in a timely fashion.

RAID log – the unique nature of projects generates uncertainty and this artifact provides a consistent, centralized method for managing that uncertainty. Without it, risks may go unmanaged, issues might not be resolved in a timely manner, actions may linger resulting in schedule and cost impacts and key decisions might be delayed or worse, made without appropriate governance oversight and subsequently reversed. The accuracy, currency and completeness of this artifact provides good insights into the overall discipline and competency of a project manager as it is their ultimate shield. If a project manager is not concerned about self-preservation, how much would you trust them to manage your project?

Closeout report – at a minimum, this formalizes the acceptance of a project’s outputs, identify exceptions and the owners for those, and provides the necessary authority to shut down the project and to release resources. While we have all worked on projects where all concerned want to run away as soon as the work has been completed, the absence of this artifact might result in post-project headaches if expectation gaps have not been addressed.

There is an elegant symmetry to this list – the charter and closeout report bookend the project, the approved plan and current forecast are ideally identical twins, and the RAID log acts as the main monitor and control tool.

Have I missed any artifacts which you feel are mandatory? Do you feel any of these Famous Five are unnecessary?

Don’t forget to leave your comments below.

Agile Project Manager: WHIPping Things Into Shape

Written by Robert Galen on October 30, 2013. Posted in Articles. 8 Comments on Agile Project Manager: WHIPping Things Into Shape

I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.

But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.

One particular team truly struggled. They had failed quite a few sprints in a row and I was intervening as a coach. Let me digress for just a moment on the whole failure thing, before you all start throwing tomatoes:

We measured success or failure not by hours, or points, or stories completed. We measured it by the team meeting their Sprint Goal that was established when they planned and committed to their sprint. There is a lot of angst in the Scrum community over using Pass vs. Fail or even using the word “commitment”. For the purposes of this article, I do not necessarily want to try and debate this practice. You can see references to some related posts at the end of the article. Suffice it to say that, at the time of this example, we measured and cared about sprints passing versus failing.

As they failed, they would talk about adjustments in their retrospectives. But the modifications were often quite trivial or safe. I felt they were not addressing the issues that were truly impacting their performance. I remember in one retrospective, they decided that the estimation units they were using were flawed. So they moved from a modified Fibonacci to Gummy Bears. Needlessly to say, the next sprint was not positively influenced by the adjustment.

This went on for quite some time.

I am normally a patient coach and I try to influence teams to observe and improve on their own. But this team truly was not “getting it”. So, after about their fourth or fifth failure in a row, I gathered the team’s Scrum Master and Product Owner in my office for a “chat”. I insisted that the failure pattern that they were experiencing needed to stop. I told them that I felt their root problem was that the team was not collaborating on their work. That they were operating as a Scrummer-fall based team and that individual work was the norm rather than teaming, swarming, collaboration, and teamwork. They agreed and they voiced their own frustration with the lack of improvement. But they did not know what to do and they were reluctant to “tell” the team what to do.
I quickly suggested two things. But the change had to be theirs. If they did not like my adjustment recommendations, then they should pick meaningful ones of their own, but they should stop dancing around the root challenges and truly attack meaningful adjustment ideas in their retrospective. Clearly, something had to change – for the team’s sake.

My Two Adjustments

I recommended two simple adjustments for their team:

First, I asked them to co-locate or sit together as a team, find a place where they could all sit together for one sprint. I spoke about the quintessential Agile team environment, where everyone sat at a long table – along both sides. The entire team residing in a single room, where they could see and hear each other and where they would be naturally pairing. A room where they could pull away from the laptops and gather around a whiteboard and where they could have their daily Scrum right there in the same space.

Could they just try it…for only a 2 week sprint?

Next, I asked them to limit their work-in-progress or WIP. I did not necessarily have a “magic number”, but I thought that a WIP limit of three might be useful for them. And, as a note, this would be a hard limit. The team could only work on three user stories in the Sprint Backlog at one time. These would be the highest priority stories. In order for them to pick-up the next story, they would have to complete one of the current three and demonstrate that it met their definition of “done”.

That was it. Two small changes fully targeted at their collaboration challenges.

Well, fast forward past their next retrospective and the team “accepted” my recommendations and tried them out. They found a large conference room that they took over as a team room and everyone moved into the room: front-developers, testers, back-end developers, Scrum Master and the Product Owner.

The whole team co-located for a sprint.

Their sprint planning went on largely as before, but the workflow strategies were strongly influenced by the WIP limits. In fact, they only planned on attacking the first three stories, leaving the remainder of the work to emerge during the sprint. So, they did a bit of guessing on how much would fit into the sprint.

But, importantly, they left sprint planning with a commitment to a body of work and a commitment to swarm on their work as a team. They were willing to give the adjustments an honest try.

Results

I rarely like to use numbers to illustrate results because they can be misleading and miss much of the nuance. However, in this case, I want to leverage some of the team’s numbers simply because it illustrates the impact these modifications had AND the results the team realized.
The team previously would commit to a body of work and deliver only 60-75% of the work (stories) toward their sprint goals. That was typical. They also often missed delivering higher priority stories over lower priority stories.

The sprint where they made these two adjustments, the team delivered to 140% of their commitment; pulling more work in than they had thought feasible. Not only that, they delivered in priority order, so if something had happened they would have delivered higher value first.

But there is even a hidden fact I have left out. It just so happened that this team received a new team member a few days before the sprint started. While being an experienced engineer, this person was totally new to the company, product, and team. As part of the team’s renewed focus on collaboration and swarming, they embraced the new developer and he actually had a net-net positive impact on the sprint’s results.

What Changes Do WIP Limits Influence?

Even before Kanban became more popular I was leveraging WIP limits in my coaching as an aid to driving collaboration and swarming around work. The reality is that when a team swarms around their work and removes delays, hand-offs, and inspection points, they simply get more done. But it is often hard for some teams to realize it.

Getting back to our team, what did they experience over their initial sprint?

The daily Scrum became more of a collaborative planning session than a status meeting for the team. The discussions surrounded who would work with whom to maximize their focus on the limited WIP and effectively working together.
Since the team only had a few things to work on, keeping them “flowing” towards completion was important. So any delays, impediments, or issues became immediately visible and required team-wide adjustments. This helped in getting work “done” as well as improving their throughput.
It was funny. Even though they all sat in close proximity, the team had not truly collaborated previously. But removing all of the walls and getting everyone co-located changed the collaborative dynamic. There was much more dynamic pairing across team members and natural cross-team communication.
Another aspect of the room was work visualization. There was a shared whiteboard where the team had their sprint plans. Story and task card movement was incredibly visual and the team spent time at the board every day adjusting their visualizations for work pairings and workflow.
Quality was better as the developers and testers paired more frequently and naturally. They found bugs quickly and focused on repairing them rather than talking about or documenting them for later resolution.
As I mentioned earlier, the team really did not plan the sprint end-to-end in the traditional sense. Instead, they planned each new story as they picked it up, changing their collaboration as required. It was dynamic, fast, and optimized the throughput of the team towards getting things DONE!

The key conversations in the daily stand-up moved from “What has each individual done or what do they plan to do?” to “How does the team maximize their daily focus to get the highest priority work done as quickly and as well as possible?”

Wrapping Up

As for my example team, some might wonder what happened after that initial sprint. Did they move back to their old offices? Did they change back to their old habits? And did they continue to improve?

I will leave that answer for another time and another article.

The real point is – are you struggling to collaborate as a team? Are your developers holding on to work too long? Do you have too many stories in play at once and miss delivering important work? Is Scrummer-fall alive and well in your organization? Or are you just not as productive as you think you could be?

If so, please consider sitting together and limiting your WIP. You just might see a different result.

Don’t forget to leave your comments below.

Implementing IT Governance – A Perspective

Written by Mike Morton on October 9, 2013. Posted in Articles. 90 Comments on Implementing IT Governance – A Perspective

Today businesses rely on information technology (IT) as an integral part of their overall enterprise strategy. For the same very reason, a new field of thought called IT governance has been under development for several years. Just as business management is governed by generally accepted good practices, IT should be governed by practices that help ensure

An enterprise’s IT resources are used responsibly
Risks are managed appropriately
Information and related technology support business objectives

In other word IT governance is the process by which decisions are made around IT investments.

Although the level of maturity and acceptance of IT Governance varies considerably across different organizations and sectors but a number of different views emerge in its favor. These view, though present conflicting arguments but favor the implementation of IT Governance.

IT alignment to the business is the highest rated driver and outcome of IT Governance practices. A large majority of organizations recognize the importance of IT alignment in order to deliver sustainable business results, and feel IT Governance is the best means to achieve this. A general understanding among all the organizations and their CIOs is

“The successful application of IT Governance principles can provide a mechanism to increase the effectiveness of IT and, in turn, meet the increasingly high demands from business for IT.”

The results of effective IT governance can be transformational. The current climate of cost reduction and budget restriction has resulted in new norm – there is an expectation that IT resources should always be used as efficiently as possible and that steps are taken to organize these IT resources ready for the next cycle of growth and new IT developments. There is a wide acceptance of the fact that the IT Governance is required and investment in IT to deliver full value, it is recognized that IT has to be fully aligned to business strategies and direction. Implementing right governance for IT, business aligned strategy and right set of IT Governance tools can provides a large number of benefits for organizations. These benefits can be observed by all the stake holders in the organization through different means and metrics.

Executive Management: Executive management will see the improvement in the quality of IT services over time. There is also a reduced failure of IT projects, minimizing risk and saving cost.

Business Owners: For business owners there is major reduction of IT risk over time. There is also a reduction in cost of delivering IT service over time.

Other Managers: For other managers in an organization they will experience enhanced delivery of IT Services.

All IT Workers: Projects undertaken are followed up as well as operations in the organization. This leads to fewer surprises and less frustration. As an organization starts implementing IT Governance tools, more benefits will be released and the benefits can be measured.

Though, we talk very highly about the importance of implementing the RIGHT STRATEGY for IT Governance and Organizations spend money and effort in that direction, but there remains the fact that IT governance implementations fail, and lead to a disastrous results for the stakeholders. Moreover, IT Governance is still very much associated with fulfilling control or compliance requirements rather than it being an overarching framework that can be used to enhance the value of IT for the organization. There can be an unending debate about the reasons of the failure but let us accept the fact that the risk of IT Governance and Management failure is not so trivial. Gartner, on one hand, says 50 per cent of projects are rolled back out of production, Carnegie Mellon, on the other, says 25 to 40 per cent of all spending on projects is wasted as a result of re-work.

Despite these frequent reminders on the costly consequences, there is still evidence that many organizations do not place sufficient executive attention on this issue.

“We’ve always done it this way.”

That simple sentence has probably been uttered millions of times in businesses around the world. Usually, the people who say it are sincere; thinking the way they work adds value to the business. This always leads to a situation where “IT Governance is driven by top management”, and is often associated with ‘strong’ CIOs who have the full support of executive management, with a resultant reduction in the risk that the implementation effort will be faced with staff and business management resistance.

“What is the value add out of it.”

The benefits of implementing IT Governance are not measured and are difficult to quantify. In many instances the desired benefits are not defined upfront, which makes it impossible to measure them. When some organization went out to measure the performance of IT Governance practices, they start by measuring how it works in terms of performance indicators, but only a small number of them measure hard benefits or the eventual outcomes of the governance practices.

How to overcome challenges

Responding effectively and better executive support, a growing number of experts believe that can help the situation. Part of the problem is attitudinal, where many organizations view this as another unfunded mandate; a needless expense far removed from any kind of profit center. In our view, effective IT Governance needs to draw on 2 things –

Implementing right governance body

According to the IT Governance Institute, IT governance is the responsibility of the board of directors and the executive management, and is an integral part of enterprise governance. It elevates information as a key organizational asset and treats governance of information at par with governance of other assets like human, financial, intellectual, and relationship assets.

Governance body is extremely important and foremost step in implementing the IT governance tool. It is expected that this body / structure within the organization will define expectations, grant power, and verify performance. This body also establishes the strategic, operational, and technical decision-making process which is extremely critical. This helps to manage sourcing, assign trained and capable resources to govern sourcing relationships; put appropriate processes, escalation procedure to keep an open dialogue, create the disciplines around monitoring, reporting, changes, and feedback, and employ the right tools.

Each organization is unique in terms of their vision, set of customers and processes and should evolve its own governance model based on its own particular circumstances. Organizations which have no IT governance at all should start small and steady with an advisory body with strategic planning, standards making, and project prioritization and should also add more functions to the governing body as it and the organization matures. These organizations that are employing some form of IT governance may wish to expand their body further into decision-making and performance management.

Governance body need to decide who will decide when it comes to verifying performance, defining what is accepted. This is often controlled by the size of the organization and at what level the governance committee has authority over implementation. Many believe that IT governance should sit at the highest level of the organization and should strictly the domain of CIOs, CEOs, and department heads. This is unfortunate because these same principals can scale down to the department level or even smaller business units. There is room for IT governance wherever there are decisions to be made regarding how to utilize technology resources to make a unit function better. Rather than only heads, the whole team commitment added innumerable edge in implementing an IT governance tool successfully.

To attain the optimal results, the IT governance body should be responsible for the following:

Establishing and communicating an organization-wide IT vision that supports the mission and goals
Establishing IT policies that support strategic & IT priorities
Establish and control the overall budget for total spend
Suggesting or recommending technical architecture and standards
Establishing best practices and recommended governance tool

Implementing a Governance Tool

Other than deciding what role IT governance body is going to play in the organization, Tools for managing IT governance can be developed, created in-house or purchased from a third party vendor. Tools provided by third parties are maturing and growing in popularity. There is nothing like one size fits all when creating or adopting IT governance tool.

Organization should select that tool which could facilitate governance and improve their reporting, automate and standardize processes, simplify and reduce administrative burdens; improve staff effectiveness to optimize scarce resources; and reduce the overall costs of governance.

Organization need to understand strengths and weaknesses of the leading tools and match them with their growing and immediate needs. They should also be ready to invest in proof of concept and generate a set of real life working conditions against which tool can tested.

Implementing IT governance tool is an important step in becoming a more responsive IT entity in today’s ever increasing challenging world. This process should be approached with all the planning, research, and resources that are fitting a major project or program for your organization.

The needs of the organizations could revolve around the below areas:

Performance measurement and reporting
Financial analysis, reporting and processing
Contract management
Process automation and workflow
New ideas generation and conceptualization

A department-level, division-level, or bureau-level IT manager has no reason to shy away from this process. Organization should make sure that its stays in sync with the goals and objectives and strategic vision of the governance committee of organization’s higher body.

Challenges and way forward

Organizations should approach this very meticulously while selecting and implementing the IT governance tool. Many of the tools cover only with some limited capabilities which may not fulfill all the needs (immediate and future). To get the entire desired functionalities one may consider buying multiple applications and a varied degree of customization. Below are some pointers when it comes to selecting and implementing a sourcing governance tool from third party vendor.

Carefully consider and document your requirements
Consider the internal tool landscape
Costs for licensing and implementation vary widely
Understand the different solutions on the market
Conduct a proof of concept as part of the selection process

Case Study

A big IT organization’s management team including Project Management, Program management, Service management and Demand Management wanted to implement IT governance tool to streamline their processes. With a list of domain experts with diverse experience, they had an internal session where they nailed the problem and decided to implement a tool. It was a rigorous process to select right tool and implement and this took almost 6 months of duration. To everyone’s surprise, this tool was rejected after 6 months of Go-live claiming this does not fit organization needs. Another tool was evaluated with a lot of brain storming sessions and finally implemented. This tool also failed to live up to expectation and could not yield the desired results.

Now the question, “Is there really a tool which can help this organization?” This led to engaging a professional team to evaluate and recommend right tool. Professional team, after a month’s study suggested the same tool which was rejected few months back. In their finding, they clearly identified the gaps and documented those.

A tool can strengthen existing process but will fail if process does not exist
A tool can bring in transparency but cannot force compliance to process
A tool can enhance reporting but will fail to add value unless reports are analyzed and corrective actions are taken

An assumption that implementing IT governance tool will solve all the existing organizational problems is like taking the first step in wrong direction. Process owners need to revamp and make sure that processes exist at the first place before they look outside for a governance tool to implement and expect it to work efficiently. No tool in the world can optimize a non-existent process. The Governance body must look inward first to make sure that processes are there to be optimized and people are mature enough to embrace the change which the tool will bring.

Don’t forget to leave your comments below.

References:

10 Lessons Learned When Implementing a Stage-Gate® Process for New Product Development

Written by Mark Barnett on September 18, 2013. Posted in Articles. 8 Comments on 10 Lessons Learned When Implementing a Stage-Gate® Process for New Product Development

Projects can represent an investment of billions of $US over a development period that can be as long as five or more years. With such large investments at stake, it’s important to use a well-integrated set of best-in-class tools and methodologies to reduce the risk of either a less-than-projected return on investment, or worse, a total failure. If the chosen approach can also reduce the new product development (NPD) cycle time, its value is even greater.

Many large organizations have adopted a gated approach to reduce NPD risk. One of the key features of such an approach is a set of “go/no-go” decision gates which, in principle, ensures that each project remains aligned with its original strategic intent and its value remains high enough to justify its continuation to the next stage of development.

As well as processes and methodologies, there are a few fundamentals that companies must remain true to when developing new products: call them best practice or just plain common sense. Sometimes small deviations from these fundamentals cause problems. On the other hand, small modifications may be identified that make the process work even better in situations that are a little different from the usual.

The message here is flexibility: while adhering to the process and fundamentals of NPD, keep an eye out for situations that demand something a little different—some nuanced modification that improves the process.

The following are 10 lessons learned when the business units of one of the world’s leading Oil & Gas upstream services companies, with over $20B in annual revenue, decided to revisit their processes to optimize the return on investment of individual NPD projects. The process used, Stage-Gate®, is time tested and well understood, but a focus on the business case, risk management, cross-functional collaboration, and integrated launch planning, versus just “following the process,” provided the fundamentals necessary for success. And a handful of other practices that were added made a critical difference in ensuring NPD went off with fewer problems and surprises.

One important conclusion resulting from using the gated NPD process implementation is that there are five distinct components, all of which must be embedded in any NPD methodology to maximize its effectiveness. They are:

A robust business case
A strong risk-management approach
A comprehensive integrated launch plan
A governance discipline where leaders are genuinely engaged and accountable
Clear ownership of and accountability for the NPD process

The Second Half of Best Practices for NPD Success

But what are some best practices beyond these five well-known known components? Here are five more:

1. Don’t ignore (proven) advice

Few organizations want to deliberately ignore lessons learned from others who have executed similar initiatives. For example, there are 10 tips for successful implementation of Stage-Gate that 2 of its leading experts have shared. But what happens when a company only heeds eight out of the 10 and, further, does not fully follow those they do “adhere” to?

Often, the lessons not followed lead to gaps and weak points in execution. In this Oil & Gas company’s Stage-Gate implementation, the leadership’s conscious choice not to emphasize change management and internal communication delayed the adoption timeframe by up to six months And the final outcome? The organization had to double back to address the large implementation gaps created.

2. Avoid overkill

When this initiative started, the gated approach was defined in full-blown form, describing the process that the largest, most complex, and highest-risk NPD projects would follow. After an initial set of large-scale projects (roughly one per business unit) went through a pilot phase of the Stage-Gate process, demand for the use of the gated approach for a wider range of projects grew. However, it quickly became apparent to many of those who wanted to apply Stage-Gate that it would be overly burdensome for smaller, less risky projects to adopt the same level of detailed documentation and governance oversight.

Fortunately, others external to this organization had already developed a set of best practices for scaling the Stage-Gate process for projects of different sizes and degrees of risk. Drawing from that work, three versions of the Stage-Gate process are now used, differentiated not by their relative degree of rigor, since that is the same for all three processes, but by the management level of the members of the governance committee, the degree of formality of some specific gate reviews, and the level of detail of the documentation required. Along with the scaled processes, a set of criteria for determining which process a particular project should follow is also in place. The organization based those criteria on the level of risk and complexity and the magnitude of the financial investment required for each project.

3. Understand the process

If the Stage-Gate process is a framework that overlays an existing NPD process, then a primary exercise in implementing that framework is to align stages and gates to the existing process. This presupposes that the existing NPD process is well understood and well documented.

But, as was found in this instance, trouble will ensue when each business unit’s understanding of the process resides primarily in the heads of veteran employees, and those NPD processes, because of the numerous known or suspected gaps and deficiencies aren’t necessarily what the organization’s leadership wants to see emulated.

With this in mind, it shouldn’t be surprising that one of the most powerful exercises carried out during the Stage-Gate deployment discussed was the development of detailed process maps representing all major work streams within the entire end-to-end NPD process.

While the maps are valuable in and of themselves, the numerous tools being developed using the information contained in the maps, such as role and responsibility matrices (a detailed RACI matrix), deliverable matrices (who owes what to whom when, using what template), etc., will be even more valuable since they will be used in day-to-day project execution. In addition, discussions among representatives from the numerous business units at each process-mapping session were important because they enabled shared insights and created the opportunity to develop working relationships with those in similar roles.

4. Use Flexibility

Another best practice that emerged is “Flexibility”—a disciplined process for allowing project-specific deviations from the baseline Stage-Gate approach adopted within each business unit. (The baseline in this case is the Stage-Gate process as customized by the business unit in the process mapping sessions.)

Flexibility consists of three elements: (1) justification for the proposed deviation, (2) identification and rating of the associated risks and, if needed, risk-mitigation actions and contingency planning, and (3) approval by the project’s governance committee for the proposed deviation.

The recognition of the need for Flexibility first emerged when a high-risk project was launched at the request of a specific customer who needed the product quickly. Missing the deadline would lead to significant financial penalties. For that reason, the decision was made to adjust certain elements of the Stage-Gate process to enable shorter execution time. Among the adjustments was the elimination of the marketing work stream, which was justified by the existence from the outset of a paying customer.

5. Prepare a software infrastructure

In the implementation described here, a comprehensive yet low-cost infrastructure was created in Microsoft SharePoint. This infrastructure significantly improved the outcome of Stage-Gate-based NPD efforts by enabling collaboration and transparency in project execution and alignment of work with the Stage-Gate framework. Among the components of this infrastructure are tools to:

Manage and share documents across all work streams and through all stages
Manage action items and deliverables
Identify, track, and manage risks
Facilitate gathering data for gate reviews
Record and communicate gate review decisions and feedback
Capture and share lessons learned

When the Stage-Gate implementation initiative started, the development of such an infrastructure was not part of the near-term plan. However, it was quickly clear that its absence was a hindrance to project execution as well as to cross-work stream collaboration. Once deployed, this software infrastructure, which was designed to facilitate each project teams’ ability to follow the Stage-Gate methodology, was quickly adopted.

Conclusions

Every company strives to consistently deliver new products that address customer needs cost effectively while achieving reliability, quality, safety, and other important customer goals. While challenging, there are a number of critical success factors that can greatly improve the odds of success.

If several components are embedded in the gated NPD approach, the chance of success of programs executed using it will increase considerably. Yet, it stands to reason that likelihood of successful products will be further enhanced by applying what others have learned the hard way—the second half of best practices described above.

Don’t forget to leave your comments below.

References

Edgett, Scott J., and Jones, L. Michelle, “Ten Tips for Successfully Implementing a Stage-Gate® Product Innovation Process,” Reference Paper #33, Stage-Gate International and Product Development Institute Inc., 2012.

Guidance for Good Project Governance

Written by Kiron Bondale on September 11, 2013. Posted in Articles. 8 Comments on Guidance for Good Project Governance

bondale Sept11 Behind every successful project is an effective governance process. On smaller projects, this governance may be primarily driven by the efforts of the project sponsor and project manager, but on larger, more complex projects you may need to have multiple governance teams and processes to properly guide and support the project.

For those of you who have not experienced the pain of managing a project that is lacking appropriate governance, here are just a few of the issues which might be encountered:

Inability to secure the committed allocation of required financial and people resources to deliver the project scope on time
Inability to get those issues, actions and risks addressed which have been escalated beyond the authority level of the project team
Protracted delays, excessive effort and staff frustration in getting key decisions made or, even worse, wasted effort and schedule impacts resulting from reversed or modified decisions
Lack of buy-in from key stakeholders
Insufficient visibility of the project’s importance at executive levels to secure sustained funding and perceived priority

If poor governance can be the cause of such lethal project impacts, wouldn’t you expect to see significant emphasis placed on this critical step?

Reviewing the track sessions for four conferences being held this year across Canada, I was only able to locate one session which specifically referenced governance in its title – while it is likely that a few more also related to subject, having attended a few of the track sessions in the Toronto conference, my experience was that this was not one of the most commonly referenced topics. This is not a criticism of that particular conference – having attended multiple project management conferences across North America over the past fifteen years, I can’t recall one where governance was a focal topic.

Furthermore, over the course of the project management capability improvement work I’ve done with companies, I’ve found that those which include a mandatory “Proposed Governance Structure” section within their project plan templates have usually done so because of lessons they have learned through the school of hard (project) knocks.

It would be impossible to provide a comprehensive guide for defining the right governance structure and process which will meet the needs of all projects as, just as with any other project management practices, these need to be tailored to the specific needs of each project and the culture of the organization in which they are being implemented.

Here are some tips to get you started:

While project complexity as a whole drives the need for greater governance, the following specific factors should be evaluated to assess the extent of governance required:
1. Degree of organization impact – the bigger the change to the organization, the more robust the governance required
2. Number of key, influential stakeholders who have or are likely to have significantly differing agendas – the greater the likelihood of divergence of opinion on project direction and decisions, the more effort will need to be spent on governance
If multiple governance bodies are being considered, make sure that there is a clear definition of the jurisdictional boundaries of each. Without this, you run the risk of getting a frustrated or disengaged sponsor who sees their decisions being overturned or questioned frequently. This also applies to standing governance committees within your organization – your proposed governance structures need to align with those as well.
If you are considering a multi-sponsor model for projects where no single sponsor is capable of or will be perceived to be providing a balanced level of governance, remember that with two or more sponsors, you will need to budget some of your time to facilitating their transition through Tuckman’s standard team development phases. You will also need to budget for the additional effort and costs of having multiple executives directly engaged with your project. Finally, you should prepare yourself for the likelihood of conflict and churn across your team resulting from individual sponsors making decisions without fully consulting their co-sponsors.
Establish clear terms of reference for each governance body detailing the types and level of activities each is responsible for as well as the overall mandate of the group. This process should start with how these bodies are named as an advisory group may be perceived to serve a very different purpose from a steering committee.
Balance the desired project benefits against the administrative costs, effort & potential delays of having an overly onerous governance process. The more gates that a particular decision or action has to pass, the greater the project costs and potential for delays. After a leadership team has experienced issues of inadequate governance on one project, their tendency may be to overcompensate on the next.

The outcome will usually not improve, and governance practices will oscillate from minimal to excessive.

Establishing the right governance structure and process is like the tale of Goldilocks – missing the mark could be “un-bearable”!

Don’t forget to leave your comments below.