Project management process:

1.  Agree precise specification for the project - 'Terms of Reference'
2.  Plan the project - time, team, activities, resources, financials - using suitable project management tools.
3. Communicate the project plan to your project team - and to any other interested people and groups.
4. Agree and delegate project actions.
5. Manage and motivate - inform, encourage, enable the project team.
6.  Check, measure, monitor, review project progress - adjust project plans, and inform the project team and others.
7. Complete project - review and report on project performance; give praise and thanks to the project team.
8.   Project follow-up - train, support, measure and report results and benefits.

 Project management tools:

1. Project plan covering project scope, project strategy i.e. approach, which of project plan, resource allocation
2. Milestone checklist: simple excel template to track project progress. Update it once/ twice a week
3. Gantt Chart: project schedule and inter-dependencies of each activity
4. PERT: Program Evaluation Review Technique (PERT) a planning and control tool used for defining and controlling the tasks necessary to complete a project.
5. MS project
6. Project reviews: In project reviews, the project progress and the adherence to the process standards are mainly considered. Usually, project reviews are accompanied by a project audits by a 3rd party (internal or external).
7. Scorecard: performance of project team.

Things project manager must look into:

1. Dividing project into task
2. Resource plan
3. Time estimates
4. Project standard and procedures
5. Identifying and assessing risk
6. Preliminary budget
7. Developing a statement of work. This document will list the work to be done and the expected outcome of the project.
8. Setting a baseline project plan. This should provide an estimate of the project's tasks and resource requirements.

PERT CHART:

PERT charts and Critical Path Method (CPM) charts are often used interchangeably; the only difference is how task times are computed. Both charts display the total project with all scheduled tasks shown in sequence. The displayed tasks show which ones are in parallel, those tasks that can be performed at the same time.[3] A graphic representation called a "Project Network" or "CPM Diagram" is used to portray graphically the interrelationships of the elements of a project and to show the order in which the activities must be performed.

PERT planning involves the following steps:

1.         Identify the specific activities and milestones. The activities are the tasks of the project. The milestones are the events that mark the beginning and the end of one or more activities.
2.         Determine the proper sequence of activities. This step may be combined with #1 above since the activity sequence is evident for some tasks. Other tasks may require some analysis to determine the exact order in which they should be performed.
3.         Construct a network diagram. Using the activity sequence information, a network diagram can be drawn showing the sequence of the successive and parallel activities. Arrowed lines represent the activities and circles or "bubbles" represent milestones.
4.         Estimate the time required for each activity. Weeks are a commonly used unit of time for activity completion, but any consistent unit of time can be used. A distinguishing feature of PERT is its ability to deal with uncertainty in activity completion times. For each activity, the model usually includes three time estimates:

-          Optimistic time - the shortest time in which the activity can be completed.

-          Most likely time - the completion time having the highest probability.

-          Pessimistic time - the longest time that an activity may take.

From this, the expected time for each activity can be calculated using the following weighted average:

Expected Time = (Optimistic + 4 x Most Likely + Pessimistic) / 6

This helps to bias time estimates away from the unrealistically short timescales normally assumed.

5.       Determine the critical path. The critical path is determined by adding the times for the activities in each sequence and determining the longest path in the project. The critical path determines the total calendar time required for the project. The amount of time that a non-critical path activity can be delayed without delaying the project is referred to as slack time.

If the critical path is not immediately obvious, it may be helpful to determine the following four times for each activity:

-          ES - Earliest Start time

-          EF - Earliest Finish time

-          LS - Latest Start time

-          LF - Latest Finish time

             6. Update the PERT chart as the project progresses. As the project unfolds, the estimated times can be replaced with actual times. In cases where there are delays, additional resources may be needed to stay on schedule and the PERT chart may be modified to reflect the new situation. An example of a PERT chart is provided below:

Benefits to using a PERT chart or the Critical Path Method include:[6],[7]

1. Improved planning and scheduling of activities.
2. Improved forecasting of resource requirements.
3. Identification of repetitive planning patterns which can be followed in other projects, thus simplifying the planning process.
4. Ability to see and thus reschedule activities to reflect inter-project dependencies and resource limitations following know priority rules.
5. It also provides the following: expected project completion time, probability of completion before a specified date, the critical path activities that impact completion time, the activities that have slack time and that can lend resources to critical path activities, and activity start and end dates.

GANTT CHART

1. They are used to show calendar time task assignments in days, weeks or months. The tool uses graphic representations to show start, elapsed, and completion times of each task within a project. Gantt charts are ideal for tracking progress. This information helps target potential timeline slippage or failure points. These charts serve as a valuable budgeting tool and can show dollars allocated versus dollars spent.
2. List all activities in the plan. For each task, show the earliest start date, estimated length of time it will take, and whether it is parallel or sequential. If tasks are sequential, show which stages they depend on.
3. Head up graph paper with the days or weeks through completion.
4. Plot tasks onto graph paper. Show each task starting on the earliest possible date. Draw it as a bar, with the length of the bar being the length of the task. Above the task bars, mark the time taken to complete them.
5. Schedule activities. Schedule them in such a way that sequential actions are carried out in the required sequence. Ensure that dependent activities do not start until the activities they depend on have been completed. Where possible, schedule parallel tasks so that they do not interfere with sequential actions on the critical path. While scheduling, ensure that you make best use of the resources you have available, and do not over-commit resources. Also, allow some slack time in the schedule for holdups, overruns, failures, etc.
6. Presenting the analysis. In the final version of your Gantt chart, combine your draft analysis (#3 above) with your scheduling and analysis of resources (#4 above). This chart will show when you anticipate that jobs should start and finish.

Benefits of using a Gantt chart include:

1. Gives an easy to understand visual display of the scheduled time of a task or activity.
2. Makes it easy to develop "what if" scenarios.
3. Enables better project control by promoting clearer communication.
4. Becomes a tool for negotiations.
5. Shows the actual progress against the planned schedule.
6. Can report results at appropriate levels.
7.  Allows comparison of multiple projects to determine risk or resource allocation.
8. Rewards the project manager with more visibility and control over the project.

Change Management

Project Change Management - a general term describing the procedures used to ensure that changes are introduced in a controlled and coordinated manner.

Change Request – Requests to expand or reduce the project scope, modify policies, processes, plans or procedures, modify costs or budgets, or revise schedules.

Tool: Clear quest Change Management: it enables submit, modify, and track change requests, and analyze project progress by creating queries and reports.

Process:

1. Identify potential change. It can be out of a new requirement or bug in an existing system.
2.  Analyze the change request: determine technical feasibility, cost and benefit of change request
3.  Evaluate change: decision of Go/ No Go for the change request
4. Plan change: The extent of the change (i.e. what other items the change effects) is determined in a CHANGE IMPACT ANALYSIS. It could be argued that this activity leads to another go/no-go decision, or that it even forms a part of the Analyze change request activity. It is modeled here as a planning task for the change builder because of its relationship with the activity Propagate change.
5. Implement Change: execute change, propagate change (The changes resulting from Execute change have to be propagated to other system parts that are influenced by it. Because this and the above sub-activity are highly dependent on each other, they have been modeled as concurrent activities.) test change, update document, release change
6. Review and close change: verify change by project manager and change cycle is completed

Components of a change request:

1.  Summary
2. Type: cosmetic, incorrect functionality, feature request
3.  Date entered
4. Entered by
5. Defect resolution: code change, document change, database change, not our bug,
6.  Priority: High, medium, low, future release, immediate
7.  Severity: causes crash, workaround, no workaround      
8.  Reproducible levels: always, sometimes
9. Version:
10.  Assigned to, assigned by, assigned date, assigned  notes

Project management Governance

IT governance is a framework that ensures your organisation's IT infrastructure supports and enables the achievement of the corporate strategies and objectives. 

Project management governance: The governance of project management concerns those areas of corporate governance that are specifically related to project activities. Effective governance of project management ensures that an organization’s project portfolio is aligned to the organization’s objectives, is delivered efficiently, and is sustainableIt is important to note that there is a difference between governance of individual projects and governance of project management. The former concerns how a specific project is governed and the latter concerns how the project management capability of the organization is governed as a whole.

Methodologies: PRINCE2 , Agile, MSP (managing successful progrmmes), MoV (management of value), PMO, PMBOK (The Project Management Body of Knowledge )

Best management practices

1.  Alignment to organizational objectives: what is important is that each and every project is able to demonstrate (typically through its Business Case) its contribution to the organization’s objectives. It enables effective decision making. It keeps projects outcome-focused rather than activity-focused. PRINCE2 addresses the alignment to organizational objectives element through the Business Case theme, which in turn is driven by the business justification principle. The Business Case theme requires that a project must have a formally documented and up-to-date Business Case. The Business Case defines the reasons for the project, which ‘should be linked to the organizational context and should explain how the project will enable the achievement of corporate strategies and objectives’. The business justification principle includes the concept of ‘continued’ justification. This means that it is not enough to assess the alignment to organizational objectives only when the project first starts; this should be done all the way through its life.
2.  Accountability:  direct chain of accountability from the most senior responsible person all the way down to the individuals responsible for undertaking work on behalf of the organization. This chain is often referred to as the golden thread. The golden thread not only needs to be based on an unbroken chain from top to bottom, but it should also be clear to everyone in that chain what their authority is and which powers are reserved for higher levels of authority. The purpose is to ensure effective decision making by defining at what level of the organization the various decisions should be made. PRINCE2 addresses the golden thread of delegated authority through the organization theme, which in turn is driven by the define roles and responsibilities principle and the management by exception principle.The management by exception principle requires that a project has ‘defined tolerances for each project objective to establish limits of delegated authority’.
3.  Reporting: An essential element of good governance is that those who are delegated authority should:

■ Periodically report progress against the responsibilities delegated to them (their accountabilities)

■ Report if they are unable to meet their accountabilities within the authority they have been granted

■ Report if there are any conflicts of interest that may affect decisions and actions they undertake using the authority they have been granted.

The frequency, content and format of reporting should be agreed at the time when authority is granted.

PRINCE2 addresses the reporting element through the progress theme, which in turn is driven by the management by exception principle. The purpose of the progress theme is to establish mechanisms to monitor and compare actual achievements against those planned; provide a forecast for the project objectives and the project’s continued viability; and control any unacceptable deviations.

• Time-based reporting involves reporting progress against the agreed plan at periodic intervals, such as weekly and daily. This typically involves producing and issuing Checkpoint Reports and Highlight Reports.
•  Event-based reporting involves reporting specific information based on certain events, such as when completing a stage, raising a new risk, a request for change or exceptions. This typically involves producing and issuing End Stage Reports, Issue Reports and Exception Reports.

1. 4. Independent Assurance: Assurance is the activity of reviewing whether objectives will be met.It is an independent check that the structure and systems put in place are adequate to fulfill the responsibilities that have been delegated and that decisions and actions taken have been in accordance with the authority granted.

1. 
   

Post 5_ Business Rules

So where do we place Business rules? In the use case or separately?

Well its at the discretion of the Business Analyst. According to me, Business rules should be kept separate because:

1. Business rules can be used across many use cases
2. They change often than the Use Cases

Use cases are about user - system interaction. Business rules are more about logic and reasoning.

If use Cases are documented in Word then business rules can be written as a part of Use case.
However creating a matrix of Business Rules and Use Cases enables the business analyst to maintain and avoid rework on each use case.

An effective way of presenting a business rule is to emphasize on only 1 concept. They govern an organization regardless of the process/work flow followed to achieve them. For example achieving sales target. Business Rules can be:

1. Access control issues
2. Derivation: Pertaining to business calculation
3. Policies of the organization
4. Constraints: enables or prohibits action

Components of Business Rules:
- Name: One liner.
For example: Minimum funds required for investment.
- Unique Identifier
For example: BR 001
- Description: It describes the rule in detail. This can be explained in text or UML activity diagram if there is an algorithem required.
For example: The investor needs to maintain minimum funds of $100,000 for investing in new hedge fund strategy. If investing in an existing strategy then minimum requirement is $50,000.
- Source : It can be reference document or any business user name.
- Related rules : To maintain tracebility.
- Revision History : Description of the change, who made the change and when was it made.
- Effective Date: Date from which it is valid.
- Expiration date: Till when its valid

Maintaining Business Rules

Best way to maintain business rules is in X - Y Matrix. This Matrix creates a link between FR ID and UC ID. So anytime business analyst needs to update a business rule, it just have to go to the matrix rather than eah individual use case.


FR - UC Matrix











If we talk about Agile methodology then UML Activity diagrams are the best way to communicate requirements. In the previous post we mentioned UML Use case diagrams as well.

So it makes sense to move to UML Diagrams.

Post 4_Writing Use Cases.

Okay Now lest focus on writing Use Cases.

So What do you understand by Use Cases? and why do we write them at all ?

Use Case is a step by step description how the user and system interact to accomplish a goal, where user can be human or another system. They are part of System Requirement Specification (SRS) document.

Use Cases provide the writer and reader with following benefits:

1. Simple to write
2. Easy to understand for stakeholders to validate requirements
3. Scenario's mentioned can be easily converted into test cases

Type of Use Cases:

• Primary / Sunny day Use Cases : 20% of the use cases are used by 80% of the activity
• Rainy day Use Cases : Prioritize them as per the development cost in something not likely to happen.

Use Case has the following parts to it :

- Descriptive Name

- Description: This is the purpose of Use case to exist.

- Trigger: Initiator of the use case. It need not happen for sure. Its just that this particular event triggers the start of the use case. This can be a business rule or it can be an external event. for example: Providing customer support periodically OR Customer calling for customer service.

- Precondition: There are two types of precondition:

1. A precondition is the state of the system and its environment that is required before the use case can be started. For example:: Appointment should exist in the system before the patient can visit the Doctor.
2. CRUD ( Create, Retrieve, Update and Delete). These are trivial requirements. Define them but dont spend to much time on them.

- Actor: Its a role performed by the user. It could be a buyer, seller, paypal (another system), agent. Actors are outside the system and must interact with atleast one use case. There are two type of actors:

1. Primary Actor: For whom the system is build
2. Secondory Actor: They exist for the Primary actor.

- Postcondition: The state of the system after the use case is executed. There can be multiple Post conditions depending upon whether al business rules have been or how the system acts.

- Basic Flow: Course of events that happens when everything goes well. Happy Flow. No errors, no exceptions.

- Alternate Flow:

1.  Error or exceptional flow that occurs at any step of the basic flow. Example: Session time out.
2. Additional flow not necessarily error based,  a flow that could happen. Example: While investor trying to invest, system gives a warnings that Stock Market will close in 10 minutes.

- Assumptions: They can be easily confused with Pre-condition. They are outside the scope of any requirement. Assumption is a condition which system assumes to be true (or false) since it does not have a way of verifying them at run time when the Use Case is executed. For example: (a) User authentication information is maintained within the authentication system. (b) All Actors communicate in English.

Use Case Diagram :

• Actor
• Use Case
• Genernalization : Reusing Use Cases
• Extends
• Includes
• Show type and sub type of actors
• Relationships
1. Between Use Cases
2. Between Actor and Use case

We will cover Use cse diagram in UML post.

Post 3_ Project Scope

Lets understand what do we mean by Project Scope ?

Its that analysis which enables the team to identify the project start or end point. Project scope covers the following aspects:

1. Why the project is initiated i.e. project statement of purpose. For example: "To make customer payment methods as per industry standards and user friendly."
2. Goals of the project: For example: "This enhancement is to add the mode of payment to customer payment option produced by customer invoicing system."
3. Identify Stakeholders
4. In scope. For example: " This project will only work on invoicing module"
5. Out of scope. For example: "This project will not cover order entry and inventory manageemnt system"
6. Constraints and Assumptions:
• Asumptions: It is important to document the project asumptions as they are based on experience, knowledge and information shared by the team members. For exmple: ' Funding will be provided before te project starts" ; "All licenses will be procured by the client".
• Constraints are the limitations within which the team needs to work in. Forexample: Schedule, Cost , Scope, resources. Each of it will have an impact on the other and will affect the quality of the delivery.
7. Project deliverables.
8. Project risk
9. Project plan/ schedule

Its mainly done by Project Manager but requirement gathering  analysis begins with understanding the Project Scope, where the role of Business Analyst comes into picture.

Business Analyst needs to have two important tools:

- Context Diagram : It describes the information exchange  between the users and the potential business system. It reveals 3 things:

• Users of the system (both human and other system)
• Boundary of the system
• High level flow of data between the systems.

- Use Case Model: It  reveals the following:

• Major units of Functionality which the system will provide - Use cases 
• Humans and systems benefitted out of those services - Actors.

The project scope is the "do to" list. Brainstorming of all the team members along with the stakeholders will be able to refer to the project scope throughout the completion of the project.

Post 2_Types of SDLC lifecycle

First I would want to cover What a BA should know. To start with lets do the type of SDLC methodologies

We would primarily focus on the below ones.

- Waterfall model

- Iterative Model

- Latest one - Agile Methodology.

Brief about each of them

Waterfall model: Also known as Sequential software development approach. It follows the sequence of steps for full requirements together. So how does it work ?

- BA finishes the Requirement Gathering phase.

- Then comes Desgin stage

- Development stage

- Integration

- Testing

- Production

- Maintanence

Once each stage is passed. Its closed. Waterfall model is good for the project where :

- Client is thorough with the requirements,

- Team is working with well understood technical tools, architecture and infrastructure.

Iterative Model: It doesnt start with full set of requirements from the beginning. Each set of requirement goes throguh design, development , testing integration and production. We develop specific part of the software, which is then reviewed in order to identify next set of requirements. produce a new version of software for each cycle in the model.

Success if Iterative model is rigorous validation of requirements and testing of each  version of the software.

Agile Model: Its an approach for effective modeling and documentation of software system. Its applied on Requirements, analysis, architecture and design.

Agile focus on shorter iterations. This helps in maintaining quality, reduced integration risk, frequent evidence of progress, good status visibility and customer relations.

The pre-determined iteration length serves as a timebox for the team.  Scope is chosen for each iteration to fill the iteration length.  Rather than increase the iteration length to fit the chosen scope, the scope is reduced to  fit the iteration length.  A key difference between agile methods and past iterative methods is the length of each iteration.  In the past, iterations might have been three or six months long.  With agile methods, iteration lengths vary between one to four weeks,  and intentionally do not exceed 30 days. 

There are further 4 types of Agile development methodolgies

- Extreme programming (XP)

- Crystal

- Scrum

- Feature driven development

Please feel free to add if you have experience in any of the agile methods.