I have been a Project Manager for over 25 years and have spent most of that time in financial application development. I have a Bachelor's degree in Accounting and an MBA in Finance and Marketing. I work for IBM Global Services and last year became an IBM Certified Project Manager. Over the years I have developed a set of reusable processes that I use for each new project I take on. Since every project has its own unique personality, I am constantly customizing and improving these processes. Reusable processes will help you get up to speed fast, start adding value and a sense of direction to your project, improve team communications and eliminate many of the negative effects of developing systems.
The following are most of the reusable processes that I developed and/or enhanced, and can easily be “customized” per your needs and work environment. The major reusable processes are Communications Management, Matrix Management and Systems Development Management—see Exhibit 1.
I look at the process of Communications Management as many links in a chain. It would be impossible to cover all the links in this short white paper. Therefore, I will cover some of the most important links that I constantly use and will have great impact on the success of your projects. The links that I will discuss are control, audit and your behavior. Keep in mind when you take on a project, you will need a clear mission, enough manpower, materials, enough time and adequate technology that need to be intertwined into your communications management.
Control Link
How many times have you taken over a project in midstream and you find out there is no Project Workbook (or Project Control Book) that chronicles the history of your project? If so, you could spend one to three months getting up to speed on what is happening on your new assignment. This is not a fun situation to be in and could hamper your efforts in making progress. If you take over a project and there is no Project Workbook, start one immediately (could be electronic) to help yourself and the project get organized. The contents should include the following “working documents” if applicable to your project.
• Statement of Work (SOW) and/or Document of Understanding (DOU)
• Subcontractor SOW/DOU
• Project Organization
• Project Plan
• Current Project Schedule
• Major Milestones and Deliverables
• Estimates to Completion
• Project Staffing
• Project Revenues, Costs and Gross Profit
• Status Reports
• Issues
• Change Control
• Client, Subcontractor and Internal Correspondence
• Financial Controls (discussed in next section)
• Proof of Deliverable Materials
• Lessons Learned (to be put in a shared database so others can learn from your experience)
The Project Workbook is a structure that is imposed on the documents that you produce. All documents need to be part of the structure.
Audit Link
Auditors have related that the documentation of financial controls for application processing is weak at best. Much personal experience agrees with that premise. How often does an auditor audit a financial system and find the following situations?
Exhibit 1. Major Reusable Process
• No documentation
• Outdated documentation
• Current documentation but not enough of it
• Everyone's documentation on the system is different
• Some key people have documentation and others do not
• The user left the company and took the system's documentation to their next job
• No sign-out and/or control procedures from the library within the I.S. Department
• No library in the I.S. Department.
The use of financial systems brings with it special needs to establish and document controls over the entire processing system. Many times there are adequate controls in a system but the documentation is not standardized. The general purpose of controls in any system is to ensure that all data is entered accurately into the system, processed correctly, the results verified and data integrity is maintained at all times. In short, you want to show that you have a reliable and accurate system. A reliable system needs to address the following four overlapping areas:
Availability—addresses whether the system is accessible when needed for processing or maintenance and the stored information within the system is accessible when needed.
Security—access to the system is restricted to only users (internal and/or external).
Integrity—system processing is complete, accurate, timely and authorized.
Maintainability—system errors or failures can be identified and promptly be corrected in a manor that does not adversely affect availability, security and integrity.
My purpose is to illustrate a financial process model for documenting and communicating the controls of your system. System designers, user management, internal auditors and independent auditors can use this process model. When writing the controls for this process, it is best to use as little “computerese” as possible. In this way the nontechnical reader can better understand the control contents of the system. The following list reflects the eight standardized process control sections:
• A—Controls Overview
• B—General Narrative
• C—Input Preparation
• D—Input Transmission
• E—Data Preparation
• F—Computer Processing
• G—Output Processing
• H—Output Reconciliation
In some systems a control section might be missing from control sections C through H because it is not needed or is not part of the particular processing. If for some reason a control section is missing, this could be an indication that there is a need for controls. If there is a need for controls, the situation should be investigated and, if possible corrected. The two most important control sections are F—Computer Processing and H—Output Reconciliation. These two control sections should always be present and well documented.
In some systems a control section might be in a different sequence. For example, control section H—Output Reconciliation, might come before control section G—Output Processing. Also, in some systems multiple control sections might be combined. For example, control section C—Input Preparation and E—Data Preparation might be combined. Also, you might have the same control features in different control sections. The controls’ write-up can reference outside documentation (e.g., Standard Procedures and Standard Practices).
Finally, it has been my professional experience that internal and/or external auditors usually become involved when the financial application is about ready for implementation or after implementation. The problem with this situation is that auditors are perceived as adding no value to the development process and are people that just get in the way. For auditors to really add value to the development process, they need to get involved day one to ensure that the proper controls are built into the financial system. By doing this, the auditors will be perceived as team members that add value to the project.
Your Behavior Link
The following are a dozen basic lessons about behavior I learned working with over hundreds of different clients and co-workers that will help you to survive. By the way, I am still learning.
• Reality. You are what you perceive yourself to be—your vision of yourself becomes your reality.
• Honesty. It is the cornerstone of integrity. Tell the truth no matter how painful it might be and in the long run your life will be simpler.
• Integrity. It is the cornerstone of leadership. Be a role model, obey your rules and behave like everything you say and do is being observed.
• Expectations. All people need to know the acceptable pattern of behavior that is expected of them on each assignment.
• Listener. Be good at it and be willing to admit your shortcomings. When you make a mistake, own up to it and view it as a learning experience.
• Peace. Admitting when you are wrong can change the mood from conflict to one of cooperation.
• Criticism. You need to be able to take it to improve yourself. If someone criticizes you, be open-minded and analyze if they are right. If you are not sure they are right, get a second or third opinion. If you know they are wrong, read the next bullet.
• Personal. Don't take things personally—if you constantly do, then you are in the wrong business. If you are upset about something, get over it and move on!
• Neutral. When management have clashes or major differences, it is usually smart to be neutral.
• Seeing. You need to train yourself to be able to see the big and small picture of your project but at the same time don't get too “bogged” down on the details—this should be someone else's job.
• Extrovert. If you are not one, you need to work (see next bullet) on becoming one to be successful in this business. One way of becoming an extrovert is to work on your social awareness by trying to become more socially aware, sympathetic, empathetic, intuitive about people and learning from others. The old saying that introverts can't become extroverts is not true. We can all change our mode of behavior if we are serious about it!
• Communication. The best form of it is interactive. I improved my communication skills (and confidence) by joining Toastmasters. Toastmasters has over 200,000 worldwide members and about 50% of the members belong to company sponsored clubs. Another advantage of belonging to Toastmasters—it will help you to think quickly on your feet.
Exhibit 2. Project Ranking Matrix
Matrix Management
By only using graphic exhibits, I will show you different matrixes that you can use (and modify per your needs) which, will be extremely helpful to you in controlling and managing your project. The graphic exhibits are simple examples that will show the Project Ranking Matrix, Flexibility Matrix, Decision Logic Matrix, Responsibility Assignment Matrix, Issue Coverage Matrix, Change Control Matrix and Risk Coverage Matrix. The matrixes should be part of your Workbook—see Exhibits 2–8.
Systems Development Management
Systems Development Management (SDM) is a structural approach to building information systems. SDM is simply a sequence of rational and logical thoughts and actions used regularly in making decisions. As such, it is an essential process used to increase individual contributions in project planning and development and to ensure project success. The philosophy behind SDM—simplicity is strength, standardization provides flexibility and consistency equals success.
Exhibit 3. Flexibility Matrix
Exhibit 4. Decision Logic Matrix
The rest of this section will be a walk-through of SDM showing the phases, process steps and major tasks—see Exhibits 9–10.
The following process steps are part of the Definition Phase.
Initial Investigation
• Project Authorization
Exhibit 5. Responsibility Assignment Matrix
Exhibit 6. Issue Coverage Matrix
• Resolve objectives and opportunities
• Prepare report stating recommendations, alternatives, anticipated benefits and/or results
• Prepare a preliminary systems study plan (schedule and costs) for the next step of the project
• Present report and plan to users and management to secure approval for the next step
Preliminary Systems Study
• Collect and review present system documentation and current costs
• Identify input an output requirements
• Develop high-level systems flow
• Identify in or out of house application packages
Exhibit 7. Change Control Matrix
Exhibit 8. Risk Coverage Matrix
• Estimate cost and payback analysis
• Prepare a system analysis plan for the next step of the project
• Present plan to users and management to secure approval for the next step
System Analysis
• Perform data verification
• Develop functional design, test and conversion strategy
• Review functional specifications with available application packages
• Prepare a system design plan for the next step of the project
• Present plan to users and management to secure approval for the next phase
Exhibit 9. Risk/Cost Relationship
Exhibit 10. SDM
The following process steps are part of the Development Phase.
System Design
• Design and review database
• Identify hardware requirements
• Identify test data requirements
• Prepare detailed logical charts for each function
• Finalize input and output requirements
• Develop implementation/conversion plan and user procedures
• Prepare a programming plan for the next step of the project
• Present plan to users and management to secure approval for the next step
Programming
• Review systems specifications and determine program modules/job flow
• Assign work to programmers
• Review database design and program specifications
• Prepare and walk through top-down diagram
• Prepare test data
• Code, debug and test programs
• Prepare program and operations/production documentation
• Test complete system
• Secure approval from management for the next phase
The following process steps are part of the Implementation Phase.
Testing and Installation
• Review conversion plan and systems test plan
• Review user training manuals and computer operations documentation
• Train users
• Test complete system in a “live” environment
• Verify results and conduct conversion
• Obtain user acceptance
Project Evaluation
• After one to three months, review how well the system meets original business objectives
• Develop recommendations for upgrading SDM to fit your changing environment.
Having and using SDM in your organization will help you realize your objectives more effectively and sooner. Your organization may use a different vocabulary (i.e., phases, process steps and tasks) than I depicted in this SDM and that is okay. The important thing is to have and use a similar SDM because the “successful” systems development process is the sum of the phased approach and management steering. In conclusion, the success of your system is the purpose of SDM and is a “Smart Start.”