15 Nov Planning a Knowledge Project

Deliverables and the Business Case

If you are a developer, a project manager, or a project sponsor of an expert system (Weiss 1984) or knowledge-based engineering project, it is very important to know early what the deliverables will be for everyone involved. Even in agile projects, where detailed requirements evolve through the course of development, you need to begin with a high-level understanding of what is to be delivered to provide some certainty to those who are paying for (and justifying) the work. SMART requirements are best.

If the expert system is designed for a company operating in a free-market economy, the end deliverable is almost always either profits up or costs down. The business case, or justification for the project will show how encapsulating expert knowledge in a system will increase efficiencies or effectiveness in a specific business function. This increase may make the company more competitive, thus bringing profits up, or decrease costs, improving the bottom line, and making the company leaner and better able to fill its mission and niche in the market. Besides commercial companies, government and non-profit organizations benefit from increased efficiency. Keeping the end goal at the forefront of the plan is important to ensure successful implementation and deployment.

Understanding Context Cross-Reference
Click on these Links to other posts and glossary/bibliography references

Section 8 #7

Table of Context

When you’re considering building a knowledge system, you must determine if the capabilities and outcomes you are seeking are possible, and if available technologies and technicians will be able to get you there. As it is often the case that your system will help knowledge workers, documenting their needs and the ways in which the system is to empower them is important. Then, as part of the cost/benefit analysis, you must determine if the costs of building the system are justified by the benefits. Before these questions can be fully answered, you need to consider the knowledge characteristics of the domain and the types of constraints affecting the knowledge. Because of these considerations, the first phase of planning always overlaps the second phase of knowledge definition.

About the Plan

There is a large and useful body of knowledge about project management called the Project Management Body of Knowledge (PMBOK). There is a complementary set of guides and standards for managing software development and the remainder of the software lifecycle called the Software or System Development Lifecycle (SDLC). Between the two, are all the fundamentals of successful software projects. But there is a lot there, not all of which is pertinent to each specific development project. In my post on Methodology, I address what I believe to be the value of applying a methodology to any undertaking like this. I am not going to describe or compare methodologies here (though I borrowed this great image from Wikipedia), but I will state that I clearly believe that the methodical discipline defined in PMBOK and SDLC is indispensable wherever the level of complexity rises beyond isolated (think integration with other systems) problems.

When a company hires an expert, it is usually to perform work that supports the operations of the company and requires expertise. When a company decides to build expert systems, it is usually because they want the computer to either help the expert, scale up the amount of work the expert can perform, or even or replace the expert.

The way you can tell if the system works is if the expert can use it to accomplish more in the same amount of time, or if non-experts can use it to get results similar to those of experts. In the development processes described in the next few sections, there are many pieces or deliverables along the way. If each piece is designed and built with the end deliverables (such as operational cost savings) in mind, the chances for success are much greater than if the focus is centered on the individual pieces.

Ask “What” Questions First

It’s always best to wait to figure out “How” to solve a problem (i.e. which technologies and designs) until after you know “What” the problem is (i.e. scope of the capabilities needed). Of course, if all you have is a hammer, most problems look a lot like nails. It may be the case that an expert system is not the best solution at all. For expert systems design, you need to ask several critical questions up front. The first is “who are the experts and can they sufficiently describe their thought processes and tasks to automate them?” Next you need to look at the nature of the data and the need to integrate legacy systems, and these may affect the selection of tools. The next set of questions involve whether current technology (such as computer technology, processor speeds, memory and database capacity, linguistic theory, parsing technology, and the like) can support the goals of the project. If the answer to that these question are yes, then you can proceed with these questions:

1. Is there a need?
2. How much will it cost?
3. Does the need justify the cost?
4. Can it be done in a reasonable time frame?
5. Will the market support the expected price of the end product?

Specifically for language-related development:

1. What target group or nation will be the primary focus of the product?
2. What languages are the clients most interested in translating?
3. Are those languages adequately described by grammars and dictionaries to automate translation?
4. Will research funding sources help defray R&D costs?

Persona-non-grata (PNG) is an old latin word used in diplomatic circles. It means you have been expelled from a country, and you are not welcome to come back to that country – ever. Getting caught spying is a great way to get kicked out of a country. Most spies know what the acronym PNG means. There are ways to become PNG in your own company. One way is to promise something and not deliver. Another is to say it will cost X dollars and then X*10 dollars later, ask for even more money. Hopefully, if you ask questions first, you will not get shot later.

First Steps First

Step 1 – Planning

The planning phase is Step 1.

Although planning is clearly the most important part of the development process, it is often the most neglected. Without carefully determining the feasibility of the project by conducting thorough technical and cost/benefit analyses, an expert system development project should not be started.

The technical analysis should begin prior to and overlap the cost/benefit analysis because technical shortfalls can be enough to terminate or delay the project until the needed people with needed skills, or the technology itself advances to the point needed to meet the requirements. This happened to Charles Babbage in 1830, resulting in his unpublished papers about computing going unrecognized for 107 years. In short, make sure the people with the right skills, the speed and configuration of machines and the capability of existing programming environments can handle the complexity of your problem.

Deliverables for the planning phase could include:

• Project agreement, project plan and/or project definition report.
• Clear knowledge of who’s who–Project manager, Project owner, Project sponsor, Project resources, Project budget manager
• Project timeline
• Status reporting schedule
• Risk analysis
• Signatures of manager, owner and sponsor(s)

There are many methodologies and templates for these deliverables, so I will not pretend that I have anything new or unique to offer. In upcoming posts, I’ll describe how knowledge projects are likely to shape up in the coming years.

Click below to look in each Understanding Context section

Leave This Blank:Leave This Blank Too:Do Not Change This:

Your email: