I recently finished a very interesting book called Power To The Public. Written by Tara Dawson McGuiness and Hana Schank, the book deals for the need for public sector entities to re-think the fundamental ways in which they plan and implement technology projects (although many of the strategies and tactics presented can apply to any project).

The Public sector has found its approach to development revolutionized through the use of data-driven methodologies, iterative development, and (most importantly in the eyes of the authors) a focus on the needs of the user and the user experience throughout the entire process.

Let's take a quick look at each of these key areas:

Data-driven Development

Successful corporations have been, for many years now, gathering an extensive trove of data on their customer base and their actions, and using that data as a key factor in all decision-making. Assuming that the gathering of such data obeys all privacy laws and common-sense treatment of customer information (and yes, that is sometimes a BIG if), it makes absolute sense to know as much about your customers as possible: what they prefer, what influences their decisions, how well your products meet their needs, etc.

An effective and robust data-collection strategy, paired with the ability to run analytics against that data, have helped the public sector grow in often phenomenal ways. Yet the private sector rarely goes to this trouble. Why? The authors point out lots of reasons, among them lack of buy-in throughout the organization and among all key stakeholders; lack of a central "go to" person to manage this process; and a definite lack in training in the private sector on what data is, and how to gather and interpret it.

Iterative Development

Public sector technology projects have been, and to this day still often are, planned and developed using the archaic waterfall methodology: write up a huge list of requirements and deliverables, give it to the dev team, wait 2-3 years (or longer!) while they build it, and ultimately end up with a final product that is now 2-3 years behind the curve.

Iterative development, famously implemented via Agile methodologies, allow for projects to be built in a far less rigid way, where new features can be added in a much more timely manner, and the specs of the project can be reviewed throughout the development process and evaluated constantly for relevance and priority.

Again, the public sector fails horribly in following these practices, for many reasons: lack of understanding of what Agile is and why it matters, lack of institutional-level buy-in, and an unwillingness to embrace the "open-ended" nature of Agile in favor of something more deterministic and rigid.

User-Focus

Probably the most important piece of information any organization can have (the authors emphasize) is this: what, exactly, do your users/customers WANT and NEED?

Notice that this question isn't "What can we build?" It focuses on defining, with as much clarity as possible, the exact needs of the marketplace, and then delivering solutions for that need.

Sometimes these solutions aren't even technology-driven! One example cited by the authors told how a public sector entity increased productivity dramatically simply by making sure certain documents were always clipped together as they move through the processing chain.

But public sector organizations rarely take the time to effectively gather and assimilate this information. Part of this is logistical: public sector orgs are often spread out nationwide, with a large amount of separation between the management team and the "boots on the ground" employees working in local/regional offices who are working directly with those in need. And as above, the other key missing piece here is simply a lack of understanding in the public sector of how important this data is; and a lack of internal champions to guide this process.

If you're in the public sector and facing just these types of issues, I highly recommend this book. Here were a few of the recommendations I gleaned based on case studies cited in the book, and actual advice from the authors themselves.

Make it personal. Technology is about improving people's lives. The key word here being people. You need to find out what real problems the people you serve are facing before you can propose solutions. You'll need to actually (gasp!) talk with the people being affected to understand the real need. This includes not only the general public, but front-line employees who will be asked to work with (and sometimes champion) whatever solution you come up with.

Find something small. Agile is all about an iterative development process, so don't take on some monolithic project right away. Find a small piece of that project which can be improved and start there. This has several benefits:

• It lets you start small and not be overwhelmed by the complexity that many government processes require.
• It lets you (hopefully!) achieve a recognizable "win" that can help others understand the value of the Agile process -- and your ability to implement it. These "others" can act as champions for future efforts and initiatives you undertake.

Find some champions. You're going to need people in your organization (and perhaps others as well) who share your vision and see its potential. They will be valuable allies in securing funding and cutting through red tape. Seek these people out, and help them at every turn so they can see your value.

Involve everyone. During your design process, get feedback from everyone. This will not only help you catch potential issues that would otherwise be missed, but it will make everyone feel involved, invested, and appreciated, which will be pay big dividends later.

Don't be in a hurry. Public sector projects typically involve a lot of stakeholders, and it can take a while to build consensus, secure funding, etc. As much as you'd like to roll something out in just a few months, the reality is it could take one or more years, even for small-scale efforts. Take your time and do it right. Make sure you clearly understand the problem after exhaustive interviews, take time to design and vett potential solutions, plan out the development effort carefully, and keep stakeholders informed at every step.

Do a soft/measured launch. When you're ready to deploy, do a soft launch that allows you to see the solution in action at smaller scale before ramping up. This will help identify "soft spots" that need cleaning up before the real rollout happens. Make sure the front-line people are fully-trained on the new technology as well. Don't leave them hanging with new tech they have to face the public with, and yet have no clue how to use.

Know what success looks like. Define early on what KPI's (Key Performance Indicators) will be a measure of the project's success/failure, and make sure you're collecting that data from day one.

Test, test, test. Nothing kills enthusiasm more than a tech project that has massive errors/crashes as soon as it's launched. Sure, errors will inevitably surface, but thorough testing should help avoid catastrophic ones that give others an excuse to bail on the project.

If done correctly, the result of all this effort is that you will have helped implement something that truly improves people's lives, and perhaps even sets the stage for more changes down the road. But it takes time, patience, and an unwavering dedication to seeing it through.