Rethinking Communication in Complex Projects Part 2

Why haven’t the traditional top ten areas of emphasis over the last 25 years resolved the problems
with project success rates?

The depiction below is a compilation of the Chaos study recommendations published over the years.

In 1994, as the first Chaos study was being published, I had 20 years of experience in project
management. I was certified in the Department of Defense (DoD) at the highest level and managed
projects in the billions of dollars. I could not argue that all of the recommendations above were
anything but appropriate at that time. I also could not see how the recommendations could resolve
what I saw was evolving particularly in larger projects. IM was phasing in at the time and accelerated in
the early 2000s when the dot com bubble occurred due to the significant turn away from details and
documentation toward a move fast, try something, break things fast and refactor, and other traits that
pushed the level of engineering to the side for many companies. Once the engineering skills were lost,
then the management layer also failed to understand the level of detail necessary for a system to
succeed and the tendency for IM to be prevalent became closer to rampant.

I still can’t argue against most recent recommendations. A team can implement every one of these
recommendations and still fail dramatically. These recommendations seem targeted at making a lot of
people feel more comfortable while they are failing. None of them are bad and most of them will help
in one way or another, but the product may still be very challenged to meet expectations unless the IM
problem is resolved. Since 2005, I have implemented a personal set of practices to counter the impacts
of IM. I have done this on my own teams and on other vendors’ teams as well. Where the practices
were resisted by other vendors, the projects were still colossal failures. Where the practices were
embraced, the products were successfully deployed and most are still in operation today.

What were the practices to counter IM?

The practices to help counter the effects of IM are focused on clarification and reduction of ambiguity in
any project. Complexity of projects will require greater diligence in using the practices with multiple
teams.

The practices include:

 Keep small teams collocated and increments of progress small.

 Coordinate business agreement with requirements, acceptance criteria and designs prior to
coding.

 Verify code implementation incrementally for business usability to achieve objectives.

When complexity and size become part of the equation, a couple of other practices are essential:

 Leads for teams concurrently develop modular design.

 Use Foundation First principles to ensure each module is in harmony with others for: data
owned and used, communication of state and action, consistent usability, and security.

Review again the top ten recommendations in the section above. Some of these practices might be
considered part of these ten recommendations; however, without being explicit, it is possible to put all
of the recommendations in place without incorporating any of these practices. Management will need
to learn that doing things that tend to make them feel good without seeing the product incrementally
satisfy the business need is just placating behavior. The practices are explained below with greater
detail to enhance use of the practices and to recommend moving away from management placating
behavior to practices that will remove ambiguity and tame complexity focused on delivering business
results.

What are the detailed explanations for the practices to defeat IM?

While detailed explanations follow, it is important to treat these explanations like project requirements
and take them through the same practices to ensure the all users are clear on what is required. We
have to stop acting like communication is perfect and everyone understands what I am communicating,
even when I don’t get to details.

1. Keep small teams collocated and increments of progress small: It is wise to keep teams
collocated. If all disciplines are not possible to collocate, then developers are most important.
The developers should also be full time. Less than full time is highly disruptive to quality of
implementation. You can have multiple small teams, but then ensure that practices 4 and 5 are
incorporated. Increments of progress should also be small. Small is relative. Agile would use a
two-week time box of effort. Shorter would not be appropriate. Longer might be necessary
with a lower competency team that is learning, but I would not recommend anything greater
than four weeks. It is too difficult to perform the other practices at the level of detailed
coordination and level of understanding required to ensure success.

2. Coordinate business agreement with requirements, acceptance criteria and designs prior to
coding: Activity is required to ensure that business requirements indicate what a user needs to
do within the system being implemented to achieve their work objectives. Always clarify each
requirement with acceptance criteria. If you are going to be true to the practice #1, the
requirements also have to be broken down to a level where they could be completed within the
small increment of progress. Then, design documentation for the increment has to be available.
The documentation, at first, can be draft versions that the business agrees could fulfill the
requirement and the team understands sufficiently to implement. Inevitably some of the design
will need to change, but without initial drafts, the likelihood of successful implementation is low.
Every resource would just implement what they believed to be right; however, without
coordination all resources could be implementing in a different way. The design is just enough
to prevent that opportunity to diverge. A more complete design can be done for the as built
capability when complete.

3. Verify code implementation incrementally for business usability to achieve objectives:
Acceptance test needs to occur with each increment at the level for which the acceptance
criteria were defined. It is OK to identify new requirements or criteria for future increments.
Acceptance can be conditional on the aggregation of capability to fulfill the business needs so
that the system would have to eventually be a complete and operational system. Without
incremental acceptance you cannot verify that you are on the correct path and satisfying what
the business needs in pieces. You also cannot give the business the opportunity to continue to
evolve their needs with the implemented system, which is often critical to get to an acceptable
final system. Technical resources should also test and verify that algorithms and business rules
are appropriately applied in these same small increments so that corrections can take place
early and often.

4. Leads for teams concurrently develop modular design: When a system exceeds one small team,
it is best to organize with multiple small teams focused on separate sections or modules for an
application or system. The teams coordinate their internal work and the leads of the teams
meet to ensure the boundaries for sections they own are clear for all other pieces under
development. At the point of integration testing across teams, include the business as well to
ensure the totality of business expectation is clarified for the way the solution works overall.

5. Use Foundation First principles to ensure each module is in harmony with others for: data
owned and used, communication of state and action, consistent usability, and security:
Multiple teams that do not communicate have proven to be a disaster. They key to
communication though is not a set of random meetings where IM takes place. Each team needs
to have boundaries established to prevent the problems that generally occur. Systems often
duplicate data. Only clear definition of which system or module owns responsibility for which
data can avoid this problem. Systems often fail to interoperate. Only clarity surrounding the
means used to coordinate the state of items shared and the sequence of activity where
meaningful can help to control this situation. Usability is in the eye of the users and consistency
requires feedback across teams to help implement business desires. The Americans with
Disabilities Act (ADA) standards need to be applied from the very first screen built so as not to
build a change nightmare for later. Standards can help the most with security; and, sharing
techniques applied in code will maintain consistency throughout an application.

Conclusion:

Improvement focus at a management or project management level is always a good thing to engage in.
Believing that this will improve the level to which technology projects are delivered is significantly
misleading if control is not placed at the communication level of implementation between the business
and implementation team. While the top ten recommendations may make an organization feel better
as they attempt project implementations, the right practices to reduce the most significant problem of
communication are much more essential to success. Informed Misperception is a significant culprit in
technology implementation projects for many reasons. These reasons must be overcome with the right
implementation practices.

Cooperative Contracts

A quick dive in to what is happening in the world of Procurement in the eyes of Contractors and Governments.

Estrada Consulting Inc.

  • National Institute of government Procurement states after conducting extensive due diligence and market research, public procurement should, where permissible by law or regulation, consider the use of cooperative contracts, in order to lower prices, lower administrative costs, increase competition, and obtain more favorable terms and conditions.
  • The 2019 Survey shows a strong favor amongst all parties for more cooperative contracts
  • By Introducing cooperative contracts, governments can help obtain quality goods and services to support effective and efficient government ensuring the prudent use of public funds.

This week the annual survey of State and Local Government Procurement Professionals was published through a collaborative effort between GovWin and Deltek which brought along with it some incredible insight in to the future of procurement from multiple angles; notably in this regard was the strong preference of cooperative contracts in the industry from both Contractors and Government’s.

What is Cooperative Procurement?

Cooperative Procurement is a term that refers to the combining of requirements of two or more public procurement entities to leverage the benefits of volume purchases, delivery and supply chain advantages, best practices, and the reduction of administrative time and expenses.

 

To understand simply, is that two or more organizations combine their resources in order to pull of a larger project that they would not have individually qualified for or been able to efficiently complete.


This allows for a more opportunity for growth and cooperation between organizations looking to gain contracts.

 

The Survey

This survey was done by testing four potential motivations for making a purchase using a cooperative contract; Time, Money, Solutions, Gap Filling.

What does this mean?

The results were heavily skewed as most organizations would prefer having the ability to collaborate and cooperate with third parties in order to efficiently pull off a project.

From a contractor perspective, cooperative purchases among government buyers helps contractors to prioritize their sales efforts across both traditional and alternative channels.

Not all businesses can qualify for national contracts, but there are also regional co-ops and statewide contracts that are cooperative in nature. For those firms who can participate, these cooperative contracts offer lower marketing costs on a per unit basis, larger per-contract revenue on average, stability of income, and potentially better overall profits as a result.

Why do we need more Cooperative Procurement?

According to NASPO (National Association of State Procurement Officials): The primary role of public procurement is to obtain quality goods and services to support effective and efficient government ensuring the prudent use of public funds. Public procurement professionals add value to every government program by:

  • Providing efficient delivery of products and services;
  • Obtaining best value through competition;
  • Offering fair and equitable competitive contracting opportunities for suppliers; and
  • Maintaining public confidence through ethical and transparent procurement practices.

In Conclusion

The benefits of cooperative contracts far outweigh the drawbacks, both contractors and governments have shown a strong inclination for it, and it will provide more competition and opportunities for all levels of contracting which will be a net positive for the taxpayers.

Seattle Reverse Vendor Forum

This week the City of Seattle hosted the Reverse Vendor Trade Show at the Beautiful Seattle Center Fisher Pavilion. 

The event as advertised by the city:

“Was an opportunity for vendors to introduce themselves to a variety of City of Seattle Departments and other public agency representatives.  Learn about upcoming solicitations, procurement opportunities, sustainable purchasing and network with other local vendors. Women-owned and minority-owned businesses are especially encouraged to attend.” (Kjell Elmer, City of Seattle)

Consultants from ECI attended the highly successful event in order to showcase and meet with officials from various departments in Washington State. 

Washington State has rapidly become an area of focus from ECI as multiple contracts have been awarded and delivered recently by our members. Most recently ECI again won a contract with Sound Transit only one year after initially winning a contract with them. 

ECI is proud to be contributing to the great State of Washington and is proud of the services and products that it provides in order to bring value to the lives of millions of its residents. 

 

BIZFILE – California Secretary of State Filing Services

California Business Connect

(CBC) is an IT project that aims to automate paper–based processes; allowing businesses to file and request copies of records online 24 hours a day, 7 days a week.

Furthermore, it will provide access to Secretary of State business records allowing the public and government agencies to perform functions in a more efficient manner and allow fee payments to be processed within one business day.

The project was approved in 2011 and is set to go public in Mid 2019. 

California BizFile was commissioned by the California Secretary of State Department which processes close to 2 million business filings and other customer orders each year. The business functions such as registering business entities and registering trademarks and service marks are handled by the Business Programs Division of the Secretary of State’s office

The Business Programs Division performs the “Filing Process” in which information submitted by businesses are reviewed for filing. The filing information is available upon request to California businesses, government agencies and other customers; some specific information is made available publicly online.

Business filings delivers numerous benefits to individuals and private and public agencies by providing information such as:

  • Evidence of the formation, registration, modification of domestic and foreign business entities.
  • Evidence of the key persons or entities operating business entities
  • Evidence of the registration and modification of trademarks and business marks.
  • Evidence for court cases and law enforcement investigations.
  • Information to government agencies for taxing, licensing, and regulatory purposes.
  • Proof of existence or good standing to open bank accounts, obtain financing, obtain licenses, enter into contracts, and conduct other official business in California.

For more information, visit www.sos.ca.gov/business-programs/cbc.

Project Overview:

The Business Programs Division performs a variety of activities in support of the core functions of the Secretary of State. The previous Filing Processes were various and based on older information technology systems and paper processes that supported the different types of filings and orders.

The Business Programs Division goal is to have all the filing and order types supported by a single set of common processes using similar systems with similar architecture.

For example, The Trademark Registration pilot has been developed and implemented based on the desired process model and using cloud-based services such as “Government Online Forms & Workflow Automation” electronic workflow (www.simpligov.com) and inhouse development of web services.

To support the desired business process and the electronic workflow, CBC Provides a cloud-based DevOps solution based on Microsoft Azure platform and .NET technologies to design, develop, and implement integrated web applications and web services to facilitate real time bi-directional transmission of data between public facing systems and internal systems of record.

On January 17, 2018, it was launched, and the Trademark Registration Online, allows you to submit online trademark and service mark registrations including required supporting documentation; allowing faster processing of both electronic and paper submissions, provides filing tips and samples to help you get your filing right the first time.

The highly successful ECI team was brought on to the project and achieved multiple milestones: 

  • Collaborated with cross-functional teams, stakeholders and sponsors to develop the business requirements
  • Incorporated an Agile mindset to help the team focus on delivering the shippable products in incremental development iterations.
  • Facilitated and collaborated across teams involved in delivering integrated modules and Led Intranet/Extranet applications, workflows, and web services.
  • Supported assigned development team when encountered problems beyond their expertise buy performing the following tasks:
    • Apply best practices in software development using Microsoft IDE, Azure DevOps, and .NET technologies
    • Design and develop web services, dynamic libraries, and web applications, using the appropriate programming techniques and languages
    • Develop and maintain cloud-based SQL Server databases and advanced SQL scripts
    • Create logic, system, and program flows
    • Write and execute unit test plans
    • Track and resolve processing issues
    • Participate in the review of code/systems for proper design standards, content and functionality.
    • Participate in all aspects of the Systems Development Life Cycle.
    • Adhere to established source control versioning policies and procedures
  • Performed Agile planning and project management using Azure DevOps
  • Developed data migration plan and led the development team in selecting, preparing, extracting, and transforming data and permanently transferring it from legacy systems to the new designed database in a cloud-based platform.
  • Acted as servant leader in establishing a continuous plan of action to improve the team’s success toward commitments and goals.
  • Applied Continuous Integration (CI) process to automating the build and testing
  • Used Azure BLOB Storage to organize and maintain the documents and attachments associated to Filing Process.
  • Designed and developed self-installing service to automate and support integration and database management back-end services

While this project is still ongoing; ECI’s part has been successfully completed. We are greatly looking forward to the tools we helped create being fully utilized by the general public.