In the 25 years that I've worked with the government there has never been a time when anyone had excess cash. Government has always been insistent that you prove the value and show them all the numbers involved up-front. Government entities are also very strict about making sure that people perform to the terms of a contract. Increasingly, government clients insist on best-value solutions that provide strong integration to existing infrastructures, or that do not raise costs by shifting requirements in terms of hardware. They don't want to buy new computers. Many applications place a huge amount of cost on the front-end investment. I get a ton of calls about our Internet-only architecture from people looking to re-capitalize existing computers in government agencies. Usually these people are dealing with large user groups. What are the biggest challenges for PeopleSoft in effectively building its products to suit the needs of government agencies?
You have a couple of choices to make in terms of how you approach the government market. Government is broken up into a variety of internal organizations. You have entitlement organizations; you have benefits; you have organizations that deal only with business and not the public. This dilemma forces you to decide if you want to build stovepipe applications specific
ROI is certainly critical. Government has the oversight of Congress or the general public. You can't hide anything about administrative overhead. We spend a lot of time with customers, and we're very careful with how we scope a project and making sure that what is being proposed specifically meets that need. We try to determine how they can introduce different features of CRM, because you must show progressive ROI. There's not a lot of patience for doing a three- to five-year program in which ROI only appears as an incremental value at the end of the cycle. There's a much greater demand for accountability, and this is increasing all the time. People are looking for results in a six-month time frame in today's government. How does the government IT staff compare to the private sector? Is it more or less of a challenge to help bring these customers up to speed?
People tend to be dedicated to this career path for a long time. They have a dedicated breadth of knowledge that is really rare. We find people all across the government sector with 25 to 30 years of experience in their agencies. Our relationships with them are part of the way we make them consider us. That's who we get the information from to design our products for the government market. These people are very committed to their agencies, and people have long memories. Which functional areas remain at the forefront of the government markets' requirements?
We've found that most government agencies are looking for the ability to more flexibly manage the inter-relationships of constituencies with information. Now, that sounds fairly ambiguous, but what it deals with is the finite data model present in so many CRM offerings. This is where costs come in. It's costly and takes a lot of time to expand that data model, to integrate other sources of information or create new representations of information. We've given government administrators the ability to build new data types on the fly. This allows the government folks to identify new relationships, apply this to CRM, and put them to work immediately, all through a meta-data managed environment.
FOR MORE INFORMATION:
There are a wide variety of differences. In the constituent's services model you have a lot more ability to recapture what has been done in the commercial packages. However, the nuances that people track against -- the 20% difference from vertical to vertical that you hear about -- shifts in other scenarios based on customization. By going to people who know government deeply and looking at what they believe brings the best value to the table, we're able to narrow the costs for implementation. This allows for both fine-tuning and lowered costs, especially compared to previous generations of CRM solutions.