Guidelines: Development of a Work Breakdown Structure (WBS)
| General Survey Guidelines |
Synopsis
Key to effectively migrating one or more Automated Information Systems within the HS Agency is gathering sufficient understanding to recommend the technology or applications that should be discarded or replaced, kept as is, modified, or built upon. These checklists and sample surveys can provide help in guiding that analysis by collecting data directly from key stakeholders.
This information is one part of understanding the current situation and analyzing the gap between the existing IT infrastructure and the HS Agency vision. This information can provide insight into how effectively the current IT inventory supports the existing HS business and indicate any issues or benefits with adapting existing technology to the future environment. Some initial items to consider surveying include:
- Application User Satisfaction Survey
- Application Technical Quality Survey
- Application Technical Evolution Survey
- Application Strategic Value Survey
The following section provides general guidelines that apply across the checklists.
General Survey Guidelines
|
Individuals collecting information about the current IT inventory or its use should be under the direction of either the Strategy Team or the Architecture Team . This helps ensure that the appropriate information and detail is collected for these teams to use. |
|
Individuals collecting the data should be familiar with the systems being used to ensure that the data is correctly interpreted. |
|
The data collection can be initiated once the scope for IT strategic planning is established. |
|
Prioritize collecting information that is important in making decisions on what must be included in the Technical Architecture to ensure interoperability and integration; determine IT strategies; and establish ballpark costs, resources, and time frames. Too much information may hinder decision making. |
|
The analysis does not need to be done all at once. It may be possible to examine a subset of the application systems if there is a natural partitioning. |
|
Surveys are not the last word; they indicate what others perceive. This input is invaluable, but has to be reviewed and carefully interpreted based on IT Strategy or Architecture Team experiences. Watch for personal biases, both from the respondents and the team. The team facilitator has the responsibility to help the team remain objective. |
![]() |
Show any significant uncertainty in the data compiled or its interpretation. Provide notes to help the HS Agency Decision Team understand any recommendations, especially if they are built on key assumptions about the use of the technology. |
|
The emphasis should be to create a representative picture of the use or maintenance of the IT as cost-effectively as possible. Focus on accuracy and speed of collection (e.g., a quick look) rather than a lot of precise, detailed information. This data is to enable the HS Agency Decision Makers, the Strategy Team, and the Architecture Development Teams to make informed decisions about the future IT with reasonable risk. Detailed data can be added later to address specific issues. |
|
Attempt to provide minimal processing or interpretation of the source data when collecting it. The data should reflect, with reasonable fidelity, the state of the use of IT in the environments within the scope at a point in time. Note all sources necessary to validate the data collected and obtain more detailed information later, if needed. |
![]() |
Accurate insight into the state of the systems requires that the respondent provide open, candid response. No information from the survey should be directly attributable to an individual or group. All responses should therefore be held in the strictest confidence, and once compiled, the source responses should be destroyed. A statement of confidentiality may need to be included with the surveys to assure the respondents that the data collected will be appropriately handled. |
![]() |
Allow adequate room for comments on each response. |
|
Use an IT glossary to define terms in the surveys consistently across the response groups. |
|
A tool such as a database or spreadsheet is useful to collect and analyze the data. |
|
Consider not only the differences, but also the similarities between the survey results. |
|
Be sensitive to the difficulties that the Team has in collecting survey data. This may be an area for later improvement. |
|
Refresh the survey information periodically as the situation changes as this is only a snapshot in time. These surveys can feed back into the IT planning. |
Sample: Application User Satisfaction Survey
The following are some sample questions to assess the current application systems from the functional use or management perspective. This information considers how well each application satisfies current user needs, enabling users to effectively and efficiently satisfy their clients. This helps identify the gap between what the users perceive as service actually received from the IT, versus what they expect. Overall attributes of the system from the end-user perspective can be examined, such as reliability, availability, safety, security, performance, and other critical attributes.
This information can help the IT Strategy or Architecture Teams consider whether to keep and build upon the existing systems.
| User Satisfaction Never | Not at all Very | Very Little/ Seldom |
Some- times/ Neutral |
Very Much/ Often |
All the time/ Comp- letely |
Don't Know |
Not Applicable |
| The application is easy to use. | |||||||
| Comments: | |||||||
| The application is available when needed. | |||||||
| Comments: | |||||||
| The application is reliable. | |||||||
| Comments: | |||||||
| The application responds quickly. | |||||||
| Comments: | |||||||
| The application is easy to understand. | |||||||
| Comments: | |||||||
| The application does everything needed to fullfill my tasks. | |||||||
| Comments: | |||||||
| Overall, I am satisfied with the use of the application. | |||||||
| Comments: | |||||||
Sample: Application Technical Quality Survey
The following are some sample questions to assess the current application systems from the developer or technical management perspective. This area considers the developer, maintainer, operations, or user support viewpoints. It looks at the internal attributes or technical characteristics of the product as well as the intermediate work products used to develop and maintain it (e.g., design/test documentation). The processes to develop and maintain the products may also be examined, such as cycle time to effect a change. This information may cover the main portions of the applications, such as user presentation, business logic, and data storage aspects.
This information can help the IT Strategy or Architecture Teams consider whether to keep and build upon the existing systems or to consider replacing or retiring them.
| Technical Quality | Never/Not at all | Very Little/ Seldom |
Some- times/ Neutral |
Very Much/ Often |
All the time/ Comp- letely |
Don't Know |
Not Applic- able |
| The application is well-structured. | |||||||
| Comments: | |||||||
| The application is efficiently implemented. | |||||||
| Comments: | |||||||
| The application is implemented with modern programming practices. | |||||||
| Comments: | |||||||
| The application is implemented with modern languages. | |||||||
| Comments: | |||||||
| The application's presentation logic is well isolated. | |||||||
| Comments: | |||||||
| The business rules implemented in the application are well-defined and isolated. | |||||||
| Comments: | |||||||
| The data manipulated by the application is well-partitioned from the application/business logic. | |||||||
| Comments: | |||||||
| The application is easy to install or upgrade. | |||||||
| Comments: | |||||||
| The application can be quickly restored to an operable state when it fails. | |||||||
| Comments: | |||||||
| The design, usage, or maintenance documentation adequately reflects the application as deployed. | |||||||
| Comments: | |||||||
| Overall, I am satisfied with the technical quality of the application. | |||||||
| Comments: | |||||||
Sample: Application Technical Evolution Survey
The following are some sample questions to assess the current application systems from the maintainer or technical management perspective. This considers the ability of the application to be readily adaptable to a changing business or technical environment. Consider portability, adherence to open standards, encapsulation, and dependency on vendor specific idiosyncrasies.
This may include the development as well as the operational environments. This information can help the IT Strategy or Architecture Teams consider how easy the applications are to adapt to changing requirements.
| Technical Evolution | Never/Not at all | Very Little/ Seldom |
Some- times/ Neutral |
Very Much/ Often |
All the time/ Comp- letely |
Don't Know |
Not Applic- able |
| The application can be changed easily. | |||||||
| Comments: | |||||||
| The application can be changed rapidly. | |||||||
| Comments: | |||||||
| The user interface changes. | |||||||
| Comments: | |||||||
| The business logic changes. | |||||||
| Comments: | |||||||
| The structure or content of the data the application process changes. | |||||||
| Comments: | |||||||
| The application can be ported to another similar operating environment. | |||||||
| Comments: | |||||||
| The application can be ported to another different operating environment. | |||||||
| Comments: | |||||||
| The application can handle a higher workload (e.g., number of transactions). | |||||||
| Comments: | |||||||
| The data can be shared across systems. | |||||||
| Comments: | |||||||
| The hardware upon which the application executes is adequate. | |||||||
| Comments: | |||||||
| Overall, the application can grow with the organization. | |||||||
| Comments: | |||||||
Sample: Application Strategic Value Survey
The following are some sample questions to assess the current application systems from the executive or management perspective. This information can help the IT Strategy or Architecture Teams consider how important this functionality is to the HS Agency goals, making it a priority when considering long-changing requirements. The HS Agency mission statements or goals can be used to generate these questions to give them HS Agency-specific meaning.
| Strategic Value | Never/Not at all | Very Little/ Seldom |
Some- times/ Neutral |
Very Much/ Often |
All the time/ Comp- letely |
Don't Know |
Not Applic- able |
| The application is critical to our mission. | |||||||
| Comments: | |||||||
| The application allows us to effectively provide critical services to our clients. | |||||||
| Comments: | |||||||
| The application responds to changing business requirements. | |||||||
| Comments: | |||||||
| The application provides a good return on the investment to maintain and operate it. | |||||||
| Comments: | |||||||
| Overall, the application has strategic value to the organization. | |||||||
| Comments: | |||||||


