Technical Writing - Resources

Software User Assistance Project Management (contd..)

Phase 4: Develop a UA Solution

Develop each UA system’s module as an independent entity that can be tested in isolation, to enable verification of its content and functionality.

Planning

For this methodology to work, you need a project plan for each project you undertake.
Your plan must be capable of providing the following:

• Clearly identified resources throughout the life of the UA system project.
• Built-in contingency time to allow you to manage problems without affecting the key delivery dates.
• Well-defined milestones to represent key dates by when you must deliver certain deliverables. Milestones are vital for monitoring progress.
• Clearly identified dependencies indicating both your responsibilities and the customer’s responsibilities.
• Tracking mechanisms to track your UA system’s development and the team’s progress.
• Identification of Risks and Risk Assessments for the entire life of the UA system.

UA System Reusability

Ensure reusability of the UA system by developing independent modules in it.   

In general, projects rarely run smoothly. Always make room to handle complications.

• Contingency Time – This time provides the slack that lets you handle complications – up to a certain point. If you have contingency time due to an early completion of your UA system, store it; do not waste it. Contingency time is one of the main arrows in a team lead’s quiver to handle complications.
• Resources – Keep them happy. Plan variation in their work. Some UA creators are better than others – some are good at content creation, some are good teachers, some good at finding bugs – some good at technology. Identify the strengths and weaknesses of each resource. When a complication arises, you know the best resource who can react to the issue.
• Small Teams – The advantage in a small UA team is – everyone knows what the other is doing. It brings about a focused team spirit and when complications arise, team members pitch in to solve the issue. This spirit is less obvious in large UA teams, where each member has a smaller identity. Another character of small teams is that they are faster to react to complications than bigger teams.
• Leading a UA Team – A team is only as good as its leader! The Team Lead must have primary management control of the UA component of the software application. Generally,  a Team Lead addresses technical issues; consequently he or she must also have good knowledge of the UA authoring tools, the UA system, as well as the software application.
• Escalation Chain – Every UA system project must create an Escalation Chain. The project needs a means by which issues can be moved, or escalated, through a series of levels, with each level involving more senior project members both from the UA system and the software application. The underlying principle is that if you are not able to resolve an issue, the person up in the chain is likely to have more experience and influence to do so. That person may not always be able to solve your issue directly, but he or she can point you in the right direction.
• Replanning – In extreme cases, certain complications in the software application’s project might need you to replan part, or even the entire project. Replanning a project in progress is very difficult. Many activities may have already started, some activities may be complete, and some may be nearing completion. Attrition of resources belonging to a project is also a possibility. Replanning a project is like hitting a moving target. 

Change Management

Managing changes to the design of the UA system is critical. Use an efficient change management tool like Caliber to record these changes and note the reason for changes.

Changing Goal Posts

At times, the customer may not fully appreciate what the requirements are until the system materializes and the customer starts using it. If that happens, someone failed to capture the requirements in a way that highlighted the customer’s true needs. By this, I mean the customer in some way changes the basic definition of the project. This could have a devastating effect on the timetable if the change is not handled correctly.

• Changing the Requirements – In the Requirements Capturing phase, you have found out what the customer’s future requirements will be, if you have done this right, you understand where the customer eventually wants to go with the UA system that you are ready to develop. Chances are that the goal posts will shake, but not move, as the project progresses.
• Changing the Schedules – If you find the Customer demands it, but you must be aware that you have only a certain number of resources and a limited capability. In all probability, the changes in schedules were a result of late deliveries of the software application in the first place!
• Managing the Customer – In addition to managing the project, you must also manage the customer.  The Customer, being the king, would need a lot of consideration. Have a strong contractual platform in place on which you can conduct negotiations; you can then manage the customer’s expectations, demands, and concerns. Your ability to manage the customer will be only as good as the tools you use. At times, you might have to give, and at times, you might have to take.
• Strong Contractual Platform – Have a strong contractual platform from which to conduct negotiations, you can manage the customer’s expectations, demands, and concerns. Your ability to handle the customer will be only as good as the tools available to you. Sometimes, you have to give, and, sometimes, you have to take. Being tough is sometimes necessary to manage a customer who might turn up with unrealistic expectations. At the same time, giving in a little here and there would fetch you a reputation of being flexible, and then when the time comes for some help from the customer, you will find people are more willing.
• New Requirements – Assess new requirements. Always ensure that they do not compromise the current design of your UA system. 

Phase 5: Identify UA System Integration and Testing

Integrate all the developed UA modules, and test the completed system as a whole. Then, integrate it with the software application and test it again.

Testing and Support

Ensure that UA Testing and UA Support is part of the UA system’s life cycle.

Types of UA System Testing

• Manual Testing – The UA creator manually clicks hyperlinks (online) and checks cross-references (paper-based).
• Automated Testing – Try to set up a batch of tests of whatever you would do manually, and get the results into a file. Run this batch file at the end of your workday and see the results file the next morning. You could also get hold of a good automation package like Rational Robot or Test Director that would provide you with the details of the tests performed.
• Regression Testing – A version control tool such as Visual Source Safe or Rational Clearcase tracks changes and ensures that a previous version of the UA system does not overwrite newer versions and allow old bugs to creep in. Perform sufficient tests to ensure that a new fix has not affected previously working functionality, but when in doubt, test the entire UA system.
• Automation of Test Scripts – Use test scripts provided with a testing software to achieve the desired result.