insightsarticles

Guiding challenging government projects to success

By: Danielle Pelletier

01.30.17

overview industries services professionals

Government projects conducted in challenging conditions require trust, collaboration, communication, and project management acumen to succeed. Here are five recommendations for project success.

In today’s dynamic technical, business, and political environment, government projects often come with significant challenges, including undefined scope and unclear deliverables, rapidly changing influencing factors, diverse groups of busy stakeholders, and multiple vendors with work interdependencies. Although these generally are not optimal conditions in which to conduct a project, leaders often choose to move forward anyhow since doing so seems less risky than maintaining the status quo. And when faced with federal, state, or other mandatory requirements, leaders may be forced to move forward with projects they have not prioritized or planned for.

To facilitate success in such situations, projects need to abide by traditional project management best practices. They also demand a commitment to clear, open, and honest communication by all team members – government and vendor alike.

Five important activities to guide complex government projects toward success include:

Create a culture of trust and collaboration: Establish trust and collaboration with the project team from the beginning, aligning disparate stakeholders by focusing on common project goals and objectives. Doing so lays the foundation for future project communications and decision making, which is particularly important if times get tough.

Establish clear roles and responsibilities: Define roles and responsibilities early in the project to create a strong sense of ownership for assigned tasks. Doing so will ensure that government and vendor project teams avoid duplication of effort, while preventing work from ‘slipping through the cracks’. This also helps people focus on the right tasks at the right time, maximizing their involvement and minimizing their effort so they may effectively continue their ‘day job’.

Check in regularly: Hold regular checkpoints and work sessions to discuss the latest project information and changes in the current environment. This allows the team to make and document decisions to ‘correct course’ as needed, keeping the project headed toward its goals while minimizing time- and resource-consuming detours.

Define — and redefine — outcomes: Regularly confirm that work products and targeted outcomes remain relevant as factors in the project environment change. As work progresses, it is essential to ensure that links between all vendor work products remain clear and efforts are integrated. If changes are needed, follow a formal change management process, allowing key stakeholders outside of the project team to weigh in on the requested changes and document approved changes for posterity.

Communicate risks openly: Understand that risks are a normal and healthy part of any project and openly discuss them. When risks are identified early, without fear of repercussion, they are more likely to be addressed promptly, preventing them from turning into issues that negatively impact project success.

By integrating traditional project management practices with an unyielding commitment to transparency, collaboration, and communication, even the most challenging of government projects may achieve success and deliver tangible, valuable outcomes.

Topics: project management, management consulting, state government

Professional

Danielle (Ewing) Pelletier

Editor’s note: If you are a state government CFO, CIO, project or program manager, this blog is for you.

This is the second blog post in the blog series: “Procuring Agile vs. Non-Agile Service”. Read the first blog. This blog post demonstrates the differences in Stage 1: Plan Project in the five stages of procuring agile vs. non-agile services.

Overview of Procurement Process for Agile vs. Non-Agile IT Services

What is important to consider in agile procurement?

Here are some questions that can help focus the planning for procurement of IT services for agile vs. non-agile projects.

Plan Project Considerations for Agile vs. Non-Agile IT Services

Why are these considerations important?

When you procure agile IT services, you can define the scope of your procurement around a vision of what your organization intends to become, as opposed to being restricted to an end-date for a final delivery.

In an agile project, you get results iteratively; this allows you to constantly reassess requirements throughout the project, including the project plan, the guiding principles, and the project schedule. Your planning is not restricted to considering the effect of one big result at the end of the project schedule. Instead, your plan allows for sequencing of changes and improvements that best reflect the outcomes and priorities your organization needs.

Since planning impacts the people-aspect of your strategy, it is important to consider how various teams and stakeholders will provide input, and how you will make ongoing communication updates throughout the project. With an agile procurement project, your culture will shift, and you will need a different approach to planning, scheduling, communicating, and risk management. You need to communicate daily, allowing for reviewing and adjusting priorities and plans to meet project needs.

How do you act on these considerations?

A successful procurement plan of agile IT services should include the following steps:

Develop a project charter and guiding principles for the procurement that reflect a vision of how your organization’s teams will work together in the future
Create a communication plan that includes the definition of project success and communicates project approach
Be transparent about the development strategy, and outline how iterations are based on user needs, that features will be re-prioritized on an ongoing basis, and that users, customers, and stakeholders are needed to help define requirements and expected outcomes
Provide agile training to your management, procurement, and program operation teams to help them accept and understand the project will present deliverables in iterations, to include needed features, functionality and working products
Develop requirements for the scope of work that align with services and outcomes you want, rather than documented statements that merely map to your current processes

What’s next?

Now that you have gained insight into the approach to planning an agile project, consider how you may put this first stage into practice in your organization. Stay tuned for guidance on how to execute the second stage of the procurement process—how to draft the RFP. Our intention is that, following this series, your organization will better understand how to successfully procure and implement agile services. If you have questions or comments, please contact our team.

Article

Plan agile projects: Stage 1

Editor’s note: If you are a state government CFO, CIO, project or program manager, this blog is for you.

What is the difference in how government organizations procure agile vs. non-agile information technology (IT) services? (Learn more about agile here).

In each case, they typically follow five stages through the process as shown in Figure A:

Figure A: Overview of Procurement Process for Agile vs. Non-Agile IT Services

However, there are differences in how these stages are carried out if procuring agile vs. non-agile IT services.

Unfortunately, most government organizations are unaware of these differences, which could result in unsuccessful procurements and ultimately not meeting your project’s needs and expectations.
This blog series will illustrate how to strategically adjust the standard stages outlined in Figure A to successfully procure agile IT services.

Stage 1: Plan project
In Stage 1, you define the scope of the project by identifying what your organization wants, needs, and can achieve within the available timeframe and budget. You then determine the project’s objectives while strategically considering their impact on your organization before developing the RFP. Figure B summarizes the key differences between the impacts of agile vs. non-agile services to consider in this stage.

Figure B: Plan Project for Agile vs. Non-Agile IT Services

The nuances of planning for agile services reflect an organization’s readiness for a culture shift to a continuous process of development and deployment of software and system updates.

Stage 2: Draft RFP
In Stage 2, as part of RFP drafting, define the necessary enhancements and functionality needed to achieve the project objectives determined in Stage 1. You then translate these enhancements and functionalities into business requirements. Requirement types might include business needs as functionality, services, staffing, deliverables, technology, and performance standards. Figure C summarizes the key differences between drafting the RFP for a project procuring agile vs. non-agile services.

Figure C: Draft RFP for Agile vs. Non-Agile IT Services

In drafting the RFP, the scope of work emphasizes expectations for how your team and the vendor team will work together, the terms of how progress will be monitored, and the description of requirements for agile tools and methods.

Stage 3: Issue RFP
In Stage 3, issue the RFP to the vendor community, answer vendor questions, post amendments, and manage the procurement schedule. Since this stage of the process requires you to comply with your organization’s purchasing and procurement rules, Figure D illustrates very little difference between issuing an RFP for a project procuring agile or non-agile services.

Figure D: Issue RFP for Agile vs. Non-Agile IT Services

Stage 4: Review proposals
In Stage 4, you evaluate vendor proposals against the RFP’s requirements and project objectives to determine the best proposal response. Figure E summarizes the key differences in reviewing proposals for a project that is procuring agile vs. non-agile services.

Figure E: Reviewing Proposals for Agile vs. Non-Agile IT Services

Having appropriate evaluation priorities and scoring weights that align with how agile services are delivered should not be under-emphasized.

Stage 5: Award and implement contract
In Stage 5, you award and implement the contract with the best vendor proposal identified during Stage 4. Figure F summarizes the key differences in awarding and implementing the contract for agile vs. non-agile services.

Figure F: Award and Implement Contract for Agile vs. Non-Agile Services

Due to the iterative and interactive requirements of agile, it is necessary to have robust and frequent collaboration among program teams, executives, sponsors, and the vendor to succeed in your agile project delivery.

What’s next?
The blog posts in this series will explain step-by-step how to procure agile services through the five stages, and at the series conclusion, your organization will better understand how to successfully procure and implement agile services. If you have questions or comments, please contact our team.

Article

Procuring agile vs. non-agile projects in five stages: An overview