The Botswana government spent an extra $1.52M (USD) to cope with a user base that more than doubled during their implementation. See the story here.
We are to assume that they simply underestimated the number of people to be served but this does not jive with the "scope creep" comments later in the story.
Rather than a jump in the number of users -- which would be a scalability problem -- a more likely reason for the huge increase in scope is that they did not account for each kind of user. They failed to interview the target audience carefully enough to discover each unique role (job function) that would be involved.
After grasping the basic business problem at hand, defining the roles to be served by an application is the next most important task during requirements gathering. Each role, by virtue of having a different kind of work to do, will have different objectives and therefore different requirements for the application. Until an application designer knows Who they are serving, they will have an underdeveloped view of What the application must do.
The diagram below shows one way to think of systems analysis and a thorough requirements gathering process. The proper analysis path is Goals -> Roles -> Scope. We call this the "pyramid of confidence" because each new discovery builds on something more important.
