Defining the Problem

It's surprising how often developers dive into solving a problem before fully defining exactly what the business problem is. I see no reason to expect that InfoPath developers will be exempt from that temptation .

SHOP TALK
BEWARE PROJECT FEATURE CREEP

It seems to me that some uses of InfoPath are particularly likely to run into problems from inadequately scoped projects. Why? Because when you use the InfoPath wizards for relatively simple problems, InfoPath is so fantastically easy to work with. Depending on your skills and how much time you invested in scoping the project, it's easy to begin to solve a problem using InfoPath without fully realizing what you are letting yourself in for.

It reminds me of the scenarios in which small businesses discovered that Access could solve some of their pressing data storage and retrieval problems. Then they reached a point where they didn't know how to solve the next problem because it went beyond what the wizards supported and their often-limited knowledge of macros and VBA.

Of course, the problems aren't quite the same. InfoPath will be used predominantly in enterprises because of the way Microsoft has chosen to license the product. However, InfoPath encourages power users at the department level (who are not necessarily programmers) to create solutions to department-level problems. And they will succeed. But once an InfoPath solution solves an initial business need, you might want to add additional functionality. At that stage, the need for JScript, VBScript, and XML skills comes to the surface. If the need for those skills (which, as mentioned earlier, aren't rare) hasn't been anticipated, there can be unanticipated costs or undesired delays in development.

If you are formally trained or experienced as a developer, the following foundational points will all be familiar. But if you are a department-level power user , please pay particular attention to these points ”they can save you time and stress.

Gathering Use Cases

When you create an InfoPath solution, it makes a lot of sense to document the business information need that InfoPath is intended to solve. If you are planning to create a relatively small-scale InfoPath solution, there is probably no need to use formal technologies such as UML (Unified Modeling Language) or to create formal use cases. A use case is a formal description of the business needs of a project; depending on complexity, it will generally involve the use of textual description and UML diagrams. The key thing is to make sure that you take time to fully define the problem. If you are a departmental power user and find that you can't capture the data needs in a way that you can understand, you may need advice from an experienced, skilled colleague.

If you are to be a user of the InfoPath form template, set aside time to think through the problem and record what is intended. If you are to create an InfoPath solution for departmental colleagues, make sure that you spend time finding out what information everyone needs, either when querying a data source or when submitting data to it. If you see only one side of what the department does, it is all too easy to overlook parts of the necessary information that aren't important to your own workflow.

Documenting Needs and the Solution

At the risk of repeating myself , make sure you document what the InfoPath solution is intended to do, as a result of your review of information needs and/or conversations with colleagues.

Similarly, take time to document design decisions you have made. That will be enormously useful to you a few months down the line when, quite possibly, you have forgotten what you chose to do and why. Similarly, if you move on to a new post, your successor or colleagues will have a basis for understanding what the InfoPath solution will and won't do, and will be in a better position to decide whether to attempt a modification of your solution or to create a new one.

Defining the Form Template's Purpose

Make a record of what the form template is intended to do in a Word file, a OneNote file, or some other suitable format. Make sure that you or your colleagues know where the information is stored.