Please welcome our new CEO, John Conley

We are pleased to announce that John D. Conley has joined Public Knowledge, LLC as our first Chief Executive Officer. John is a proven leader in state and local government having held key strategic and operational roles throughout his career. He will oversee and improve all aspects of our business.

Conley Picture

Prior to joining Public Knowledge, John was the Executive Director for the Colorado Statewide Internet Portal Authority (SIPA). SIPA’s mission is to provide technology solutions across Colorado for all levels of government and Conley’s organizational strategy increased the number of customers from 17, when he joined the company, to close to 300 upon his departure. Under his leadership and direction, SIPA grew its revenue fifteen fold in the five years he was in charge.

John is a recent recipient of the State Leadership award, given by StateScoop magazine. He has a history of working with customers to deliver on their expectations and making sure projects are successful. It is his focus on customer service that makes John a particularly good fit with Public Knowledge.

“I believe it is important to build relationships, understand the needs of the client, and provide a great work environment for team members,” Conley said. “I look forward to joining Public Knowledge. They have a great base of existing clients and a very talented team of management consultants who serve those clients.”

Jim Plane and Ken Disbrow, the partners of Public Knowledge, LLC said: “We are thrilled John is joining us. His experience and discipline will help us continue to mature our operations, refine our service offerings, and better serve our clients. It allows us [Jim and Ken] to devote more energy to the things we are good at, namely directly consulting with our clients and developing our staff.”

Please join us in welcoming John on board.

Best Practices for Piloting an Information System: Conclusion

In the course of our work we have developed a set of eight “best practices” for piloting an information system.  This series of posts provides an summary of those practices. In previous posts we discussed the need for Executive Sponsorshipgoal setting, and expectation management and communication and project management.  Concluding our discussion of piloting, in this post we will discuss setting the pilot boundaries and dealing with what comes out of the pilot.

7. Know what you need to get started and when you’ll be done before you start.

Have a checklist of “entry criteria.” This checklist should ensure staff members are appropriately prepared, have the training they need, equipment they need, and have a means of reporting findings the minute they occur. It should also cover bigger issues such as a means of collecting and reporting findings and a defined project management plan and communication plan that is being executed.

Have a checklist of “exit criteria”. The first item on this list defines what done means. It can be when all features in scope have been exercised (or exercised a defined number of times), or you can time-box your pilot and just say it will be conducted over a month or three weeks.

Have a set of suspension criteria. If a feature of the pilot can’t be tested because it doesn’t work you pull the plug on the whole pilot? Or will you suspend execution of the pilot until the feature can be fixed?

Plan to develop a “close out” or lessons learned report. This serves as a formal endpoint for the pilot and provides a compilation of the findings, conclusions, and recommendations arising from the pilot.

8. Be prepared to deal with what you find.

As previously mentioned, you need a way to capture findings as soon as they occur. Individuals conducting the pilot are under tremendous pressure and unless they stop the moment they have an idea or identify an anomaly, they will not remember it at the end of the day. Web forms or printed worksheets work well for this.

Have a means of collecting, collating and summarizing the findings information. Ideally, this should be done daily and the information obtained shared with appropriate parties as defined in the communication plan.

Have a method of prioritizing findings. Keep it simple. Generally two categories work well.  The first are findings that must be resolved before you can go live. These are things without fixing you cannot perform your work – there is no workaround. The second are all other findings. Give those reporting the issue input to the priority, but the sponsor should make the ultimate decision.

Share your findings regularly with the pilot team and stakeholders. On a month-long pilot have standup team meetings – short 15-minute meetings – at least twice a week to review results. Share summarized versions of your findings with stakeholders as appropriate. Never gild the lily – bad news is better delivered early than late.

As part of a broad range of services designed to help you prepare for implementing information systems, Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.

Best Practices for Piloting: 3

In the course of our work we have developed a set of eight “best practices” for piloting an information system.  This series of posts provides an summary of those practices. In previous posts we discussed the need for Executive Sponsorship, and goal setting, and expectation management.  In this post we discuss choosing pilot participants, communicating with the world about your pilot, and the planning and management of your pilot.

4. Choose the right people to be “pilots.”

Typically in systems projects 15% of those affected by the system will have a very favorable attitude about it, 15% will have a negative attitude about it. It’s the middle 70%, the ones who just want to get their job done in the most efficient way possible, that should be the core of your pilot group. Choose the best and brightest from this group.  They will give you an honest opinion about your pilot and help improve the value of the pilot.  The reasoning here?  Nay sayers won’t like the system no matter what and vice versa the cheerleaders will overlook flaws that should be noted.  

Your instincts will probably serve you well here but novices typically make the mistake of choosing only proponents.  It’s the neutral crowd, the ones who will pay the price for a bad system, you want giving you feedback.

5. Communicate.

Plan to communicate. Develop a written communication plan that defines who you need to communicate to (pilot staff, stakeholders, bosses, staff that will eventually be affected by the system), what they need to know (goals and scope, the project plan, summary status information, detailed status information, closeout report etc.), how you will communicate with them (in person, via phone, by a center, etc.), when you communicate with them (before the pilot begins, daily or weekly during the pilot, and post pilot), and who is responsible for conducting this communication.

Carry out your plan, judiciously tracking each communication that occurs, evaluating the efficacy of that communication, and adjusting your plans accordingly.

Proper planning for communication and carrying out that plan helps ensure the right people are on your side should the need arise.

6. Plan and manage the pilot.

This may seem a bit obvious but you’d be surprised how many pilots we see where the system is thrown into a pilot setting with no real plan for what needs to be done and no individual clearly in charge.  Pilots are small projects. However, they are critical projects and deserve all the discipline and attention any project receives. Plan and execute the pilot according to agency or industry (such as Project Management Institute) standards. Develop a work breakdown structure, defining the tasks that need to be completed, who will do them, how much effort each task will take, and when they are expected to be done. Document the plan and communicate it to appropriate parties.

Execute the plan as any other project plan. Monitor tasks, note and mitigate obstacles, and where reality deviates from the plan make adjustments to the plan and communicate associated changes to stakeholders and team members.

Choose an experienced individual to ensure the plan is developed, executed and monitored according to standards. This is, of course, the pilot project manager.

Having a plan and manager in place will avoid having a runaway pilot and the associated costs and headaches.

 We’ll wrap up this series about piloting in our next post by discussing preparation and what to do with what you find in your pilot.  As part of a broad range of services designed to help you prepare for implementing information systems, Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.

Best Practices for Piloting: 2

In the course of our work we have developed a set of eight “best practices” for piloting an information system.  In a previous post we discussed the need for Executive Sponsorship.  In this post we discuss setting pilot goals and scope, and expectation management.

2. Set goals and scope.

At the outset you must decide why you’re doing the pilot and what will be piloted. A pilot is not a scripted test but use of the software in a production environment. The goal of the pilot is not to prove that everything works, but to find out what doesn’t work. The pilot should reveal problems with system and operational processes. If it does not, then it is an indication that your piloting process is bad, not that the system is good.

Goals and scope should include a list of features that will be piloted, and features that won’t be piloted. Remember, many business processes are cyclical; they occur daily, monthly, weekly, or even yearly. You may not test many of these cycles. Be very specific about what is in and out of scope.

The scope should also define duration for the pilot.

3. Manage expectations.

Working with the new system will not be efficient. User learning curve, bugs, and working out the software’s “fit” with your policies and procedures will take effort.  Staff piloting the system may have to perform dual entry on the “old” system while using the new system. Staff piloting the system may need backfill or at least some relief from performing regular duties. Things will go wrong. You must define your expectations for those piloting a system communicate those expectations.

Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.

Best Practices for Piloting an Information System

A pilot is a limited use of an information system in a production like environment to help determine the systems and the organizations readiness for use of the system on a larger scale. Pilots are typically limited by geographic location (e.g. It is piloted in one office), by duration (e.g. The pilot occurs over two weeks), by the features piloted (e.g. We’ll only be testing the reporting tools of the information system), or some combination of all of these. The results of the pilot are used to extrapolate how well the information system will work on the larger scale and what needs to change about the system or organization to lower deployment risks.

In the course of our work we have developed a set of eight “best practices” for piloting an information system.  Over the course of the next few posts we will discuss these practices.  The first of the best practices is to have an Executive Sponsor.

1. Executive Sponsorship

An Executive Sponsor provides leadership, tackles obstacles, makes key decisions and ultimately takes responsibility for the success or failure of the pilot. The sponsor should be a senior executive with authority over the business unit conducting the pilot. This individual must have some “skin in the game”.  There’s not a lot more to say about the sponsor other than you would be amazed at the number of pilots that don’t have one.  Pilots without sponsorship often meander and fail to really assess the systems readiness for use in production.  This in turn leads to, at best, a rocky implementation.

Public Knowledge, LLC helps public sector agencies successfully plan and execute information system pilots.

Communicating With Your Customers

Let’s face it: public sector programs and projects have “customers” – people who are impacted by or care about the outcome of what you are doing.  It doesn’t matter if you are preparing for the Open Enrollment milestone of the Patient Protection and Affordable Care Act (ACA) or building a bridge over a lake you have customers.  Poor (or failed) communications with customers can lead to misunderstandings that have serious impacts on the outcome of a program or project.  Engaging customers through timely, clear, and consistent communication promotes greater understanding between you and your customers and avoids these misunderstandings. This communication takes thought and planning.

To better communicate with customers use:

  • A plan that outlines who you need to communicate with, how frequently (and when) this communication needs to occur, what messages need to be communicated, who is responsible for preparing and delivering the message, and which media (for example, on-line, television, written brochures, etc.) will be used.
  • Language that is simple and easily understood by the target audience (for example, avoid the use of industry jargon or terms of art).
  • A methodical approach to ensuring key ideas or messages are effectively communicated (for example, identify customers likely position before you communicate with them, what position you want them to hold after you have communicated, and what methods you will use to lead them to that destination).
  • A standard template and style guide for written materials to promote consistency of formatting, punctuation, and grammar.
  • Knowledge of how customers assimilate information and learn from different kinds of media (for example, when reading on-line content recognize and utilize the “F reading pattern” to structure the format of your communication).
  • An active voice in both written and oral communications.

Public Knowledge, LLC helps public sector agencies with stakeholder outreach and communication services, including establishment of communication strategies, tactics, and plans. Some of our more recent work includes helping State agencies reach out to people affected by the ACA.

Are Your Procurements Failing?

In recent years states have noticed a drop in responses to state Request for Proposals (RFPs). This means states have fewer choices in solutions at often higher costs. To counter this trend, states must be more aggressive in promoting opportunities to attract qualified vendors. According to agency representatives of states serving smaller health and human service program populations, there may be a perception among vendors that there is less financial gain in doing business in states with smaller service transaction volumes. Individual state spending varies considerably with some states purchasing several billions of dollars in products and services annually. Other’s attribute lack of vendor participation in procurements to states being too restrictive in either contractual terms or in specification of the procurement itself. There are high stakes involved when it comes to a state’s resource investment, making it critical for state agencies to conduct successful procurements and attract qualified vendors that will deliver value added products and services. Irrespective of the specific cause, states are considering several options for promoting interest in procurements among the vendor community. These options include:

  • Hosting procurement fairs each with a specific focus (i.e., products, services, industry, etc.) to facilitate bidirectional communication between state agencies and the vendor community. This will enable states to gain a better vendor perspective and gather feedback on how states can improve procurement processes.
  • Reforming purchasing practices to promote uniform procurement rules, guidelines, and tools across state agencies and create a reliable, consistent procurement infrastructure for bidders.
  • Conducting pre proposal conferences to formally announce procurement projects and provide a platform to entertain preliminary questions from potential bidders.
  • Announcing upcoming procurement projects in advance and provide a tentative schedule to keep the vendor community abreast of procurement milestone dates.
  • Releasing the bidder’s library ahead of the RFP to provide resource materials that will help vendors gain a better understanding of the procurement project, as well as generate interest in the project.
  • Establishing creative strategies for procuring products and services that can be conveyed through an RFP, such as use of “value based” procurement techniques where the focus is on the problem to be solved rather than the solution to be purchased.
  • Revising procurement rules, regulations and even laws to balance the need for protection with the need for broad vendor participation.

Public Knowledge, LLC specializes in helping health and human service agencies with procurement management services including strategy development, reengineering of procurement practices, procurement planning, RFP development, requirements definition and technical proposal evaluation assistance.