This page is for the work on Chapter 4: Planning your Software Project

Owners of this page, please introduce yourself:

Name/ID

Name a hobby or

Something that you like to do:

Say something about your

experience with software

What would you like

to learn from this course?

How would you like

to learn from this course?

Susmita Baidya

102-15-158

Watching Movie, Reading books etc

Complete a project on

"Student Management System"

in undergraduate level

How to handle a software project from beginning to submition

The way we are going through is good

Muhammad Pasha 102-25-165

  • Reading all sort of books

(except text books)

  • Meet new peoples

  • Drawing my Imaginations

(Mind Mapping )

Only few experiences on implementing a Web Based Software on " Teacher Student Class Feedback System" for Daffodil International University

what i want to learn, is not only the Software Project Management; at the same time i would like to learn Any sort of Project Management

I think, we need do a Project, which will give us the real flavor of a Software Project and which will help us to think like a Software Project Manager. And "Form 15" can be a very good project for a Software Project Manager

Task 1: Summaries the chapter below in terms of bullets: (10 marks)

Task 2: Explain the bullets in terms of the Grameen Bank Form 15 system. (10 marks)



Chapter 4

Planning for Communications

Prepared by Susmita Baidya



Project managers spend 90 percent of their time communicating. Poor communication costs time and money and causes headaches. Communication skills aren’t easy to cultivate. If they were, everyone would communicate brilliantly and we’d live in a world free of misunderstandings.

.

The Importance of Communicating Effectively

Effective communication occurs when a clear transfer of knowledge exists between you and at least one other person. Clear and accurate communication is vital to a project success.

Ensuring accurate communication

Everyone, from members of the project team to project stakeholders, must communicate openly and accurately. Here are some tips:

Document your conversations in e-mails, memos: If you put the conversation points in writing, the party with whom you’re communicating has an opportunity to clarify various points if there are any misunderstandings.

Sign where the line is dotted: Signing where the line is dotted means that you and the other party have a deal.Here are some typical things you and the project sponsor or project customer both need to sign:

i. Scope statement: This document defines all the parameters of the project work needed to satisfy the stakeholders’ objectives.

ii. Any changes to the scope that are approved or declined should be signed by you and the requesting party.

iii. You and the project sponsor both need to sign off on the budget for the project.

iv. The project schedule must be signed by the project manager and the project sponsor. Agreement on the schedule is essential for acknowledging the project resources, identifying when the resources will be needed, and showing when the project work will be completed.

Document scope, time, or cost compromises

Set an agenda

How not to communicate

You can do more damage by communicating ineffectively than by not communicating at all. If a project team member misunderstands your solution to a problem on the project, It will be a great disaster.

The key to successful communication is to be clear. Face-to-face communication gives you a distinct advantage over e-mails and phone calls: nonverbal communications. That’s right. Sometimes what you don’t say is important too. Phone calls and e-mails can save tons of time when it comes to project management, but they also have their drawbacks.

Care and Feeding of Programmers

We have a theory when it comes to programmers. They’re not nerds, so don’t treat them that way. Here’s what you need to realize when it comes to programmers:

They are smart people.

They are creative: Programmers take nothing and make something that’s creativity. Respect what they do and they’ll do the same for you.

They can understand intangible things: Software is intangible. After all, a tool for talking to a computer to get the computer to do what you want it to do. Programmers understand this concept and they may assume that you do, too. Understand that they think logically and use deductive reasoning to get to a solution, even though they understand concepts you can’t conceive.

They often communicate in absolutes: Programmers have a tendency to go to a solution immediately or not at all.

They are proud of their work. If you’ve ever been critical of a programmer’s

work, you may have noticed his or her immediate defense of the work, an explanation of why you’re wrong,

Avoiding Communication Breakdowns

Larger projects require more detail than smaller projects. Larger projects, of course, have more stakeholders because of the size and scope of the project. The larger the project, the more demands you have on your time for planning, controlling, and ensuring that the project is executed as planned. And the larger the project, the tougher it is to communicate effectively, and the more critical it is to communicate effectively.

Facing the risks of communication meltdowns

Here are some risks of miscommunication, in order of severity, along with possible solutions:

i. Problem: Wasted time. You kill hours every day answering the same question over and over and over. It’ll drive you mad.

Solution: We recommend creating an FAQ (frequently asked questions) for your project and posting it on a project Web site. Include the Web address of the FAQ as part of every e-mail you send. When folks ask the same old question, answer the e-mail by directing them to the FAQ for a whole list of project questions and answers. Add new questions and answers to the FAQ as they arise.

ii. Of course when you waste time you’re going to be wasting dollars, but this fact also translates to your programmers. Software creation is time intensive; if the programmers on the project team are creating the wrong stuff based on miscommunications, you’re not going to be happy. You might as well throw money in the gutter —it’s essentially what you do when programmers waste time on useless code and have to start over.

Solution: Require the programmers to e-mail you weekly status reports that include “accomplishments for the week.” Hold regularly scheduled team meetings with a standing agenda item of progress and issues. Over time, lost time and money have a negative impact on programmers’ morale, confidence in you as a project manager, and desire for accuracy. When people race to meet deadlines, they make mistakes.

iii. Communication breakdowns, whether they’re your fault or not, frustrate you, your project team, stakeholders, and the end users. When these people get frustrated, they’re going to vent, steam, and grumble about the project.

Solution: You can never completely stamp out frustration, but you can manage it. Be proactive by being aware of morale problems and frustrations before they get out of hand. Never assume that people will just get over whatever issue they may have. If you see a problem, address it immediately so that mole hills don’t become mountains.

Managing communications across the enterprise

Communication can break down anywhere in the process and with any segment of people involved in the project. Never underestimate the importance of communication, even with those people you don’t have direct contact with. Ensure that you have strong communication throughout the project to all the stakeholders that are affected.

Here’s what you can do to avoid the problems we’ve dealt with:

Educate end users about the changing software and take steps to ensure that they understand what’s coming to them.

Maintain proper communication levels.

Calculating the Communication Channels

This equation gives you the number of communication channels for your project. The equation is N(N-1) ÷ 2.

N representing the number of stakeholders working on the project.

Knowing the six things every communication plan needs

Here are six demands that your communication management plan makes:

Communication explanation: The communication documents are reports, e-mails, or scheduled meetings that you need. They may not be documents only, however; communication at meetings (such as status meetings) counts, too.

Purpose: For each communication document you list in your plan, you need a brief explanation of the document’s or meeting’s purpose. You want to answer why the communication is needed and under what conditions.

Frequency: By writing down the expectations, you ensure that all stakeholders understand how often communication is needed.

Modality: The modality is the format for the communication pieces. Some stakeholders may expect a paper status report, while other information, such as schedule updates, may be preferred via e-mail. There’s no right or wrong way to present information, but the preferences and reasons for the modality have to be documented in your plan.

Duration: Not all stakeholders need project information throughout the entire project you don’t want to bog people down with information that’s not relevant to them. The duration defines how long, and when, the stakeholders will need to participate in project communications.

Responsibility: One common misunderstanding is that the project manager is responsible for every piece of communication. That’s just not true. The project manager is responsible to ensure that communication takes place, but you can’t be responsible for the actual communicating.

Setting up ten-minute meetings

If you want to be successful in software project management then you must create a plan on how you will communicate on a regular basis with your project team. One approach that works well in software project management is the daily task meeting. The agenda of this meeting is simple and requires participants to answer just three questions:

What did you get done yesterday?

What must you get done today?

What issues or problems are preventing the project from moving forward?

Ideally, this meeting lasts only 10 to 15 minutes, happens every morning, and involves only the project team.

Defining Who Needs What Information

Each organization is broken down into three parts.

Executive.

Functional management.

Operations

What executives want to hear

Two attributes affect your interaction with executives: the size of the company and the scope of the project. Here are some general guidelines for talking with executives:

Keep it simple and quick. Executives want to hear what’s happening with a project, but they don’t want all the details, and they don’t want to spend a lot of time.

Follow your plan. Your communication to executives may also be controlled by the flow of communications as described in your communication management plan.

Be direct.

Set up project summary reports as needed.

What functional managers need to hear

Basically, managers want to know how your project affects them. Managers often have their employees on your project team. They want to know:

When you’ll need their resources to work on your project?

How their resources will contribute to your project?

How their employees are performing on the project?

Whether your project is performing to expectations?

What your project team needs to hear

Here’s what programmers must hear from you:

What activities are pending: You need to let them know what work is pending and where the project should be at this point in time.

What activities are lagging: You must address issues with your project team when they are late.

What risks are looming: You need to track risks that are in play or pending in the project and keep the project team informed. Risks are any events or conditions that can threaten a project’s ability to succeed.

What issues are being resolved: You must address these problems by communicating them to the people who have the power to fix them.

What you need to hear

Progress

Issues: Your project team sees the issues and problems in the project work before you do. You must establish confidence in the project team to report these issues so that you can document them, help them address the problems, and keep the projects moving forward.

Risks: Risk identification is an iterative process. Your project team is closest to the work, so your programmers will identify risks that affect the project before you. Some project team members may feel as if they’re letting you down if they tell you about pending or new risks they’ve identified. Encourage them to share discovered risks so you and the team can deal with them.

Change orders: Instruct your team and the stakeholders on the proper method to ask for changes to the project scope. Your project team should not be doing changes on the fly, and all change requests should flow through you so can determine their validity and then catalog your decisions

Defining Communication Modalities

Modality is just a fancy way of clarifying the form communication takes. Some communication should be paper-based, while other communication should be electronic. On other occasions, a formal, face-to-face presentation is the necessary modality.

Modalities for formal communication

If you’re communicating to stakeholders in a formal setting, here are the types of communication modes you should employ:

Presentations: Throughout your software project management career you’ll likely have to get up in front of your stakeholders and present the project plan, the status of the project, or serious issues that creep into the project. Sometimes a PowerPoint presentation can help you to make your point. The secret to a good presentation is to be prepared, speak with authority, and put your audience at ease.

Reports: We once heard a project manager say, “If it’s in writing, then it’s formal communication.” We agree with the statement, for the most part. Your reports, from status to quality control, are formal. Take time to ensure the accuracy of the data you present, not to mention your grammar.

Conference/phone calls: Some of your stakeholders and team members may be dispersed all over the world, so the most efficient way to communicate with them is via conference calls.

E-mail: E-mail can be a form of formal communication in some environments.

Modalities for informal communication

If you’re communicating to stakeholders in an informal setting, here are the types of communication modes you should employ:

1. E-mail: E-mail can be either formal or informal, depending on the context. You have quick questions for project team members so you zip off an e-mail and they reply. Done. No need for fancy reports, faxes, or detailed discussions.

2. Instant messaging and text messaging: If you have a dispersed team, this mode of communication can be especially useful. It’s quick and efficient to communicate through IM or by sending text messages. The only thing you have to be concerned with is the many time zones your stakeholders may reside in. You may not want to text message someone when it’s the middle of the night in his or her time zone.

3. Coffee talk. Sometimes you need to get your team together for some camaraderie. It doesn’t have to be over coffee, of course, but coffee and donuts, pizza, whatever, can help ease the tension of a software project, let the team vent a little about the project if they want, or just let everyone know how much you appreciate their hard work. This is about motivation and team development.

- Prepared by Susmita Baidya





Answer to the Task 1: (Prepared by Muhammad Pasha)

1. The importance of Effective Communications includes the Accurate ways of Communication

2. Communicating Breakdown is never be expected, to avoid that the project manager will have to handle some risks very carefully such as :
  • Wasting Times and Money;
  • Avoiding Frustration for Communication Breakdown and
  • Avoiding the lack of Confidence.

3. Communication Channels Calculation

formula = N(N-1) / 2;

where N= number of Stakeholders or responsible peoples


4. Every Communication Plan needs six demands :
  • Explanation
  • Purpose
  • Frequency
  • Modality e.g. Formats of project reports such as Paper Reports, or e-mail updates etc.
  • Duration
  • Responsibility

5. Every Software Project manager should have a "Communication Responsibility Matrix"
  • which will represent who will communicate with whom
  • also reminds for 5/10 minutes short meeting with different groups of stakeholders
  • Dealing Who needs what information
  • and be concerned about Who should not know What information as well

6. Predefined " When Communication is Needed with Whom " is very effective idea for a Software Project Manager

7. There are some types of Communication Modes which can be used for making Formal Communications with the Stakeholders. These are:

  • Power Point Presentation
  • Reports with Status and Quality Control
  • Conference call
  • E-mail only with a reports, presentations and important attachments , nothing else

8. There are some types of Communication Modes which can be used for making Informal Communications with the Stakeholders. These are:
  • Quick E-mail if necessary
  • Ad-hoc Meetings e.g. quick 2/3 minutes session with the teams on lunch or at any break is good
  • Instant Messaging or Text Messaging for update status does not take too much time but these are very effective

9. For better Communication some Automating system can also be used for keeping the tracks of the Project status,
e.g. Microsoft Project Servers, Pacific Edge or Primavera all are these sort of Project Servers ( Ref : Text Book)



Answer to the Task 2: (Prepared by Muhammad Pasha)


1. The importance of Effective Communications includes the Accurate ways of Communication.
Before doing anything, The Software Project Manager (SPM) will need to identify the specific stakeholders of Grameen Bank to make
successful Communication with them. And The Stakeholders are the Branch Managers and the Branch Employees of Grameen Bank


2. To avoid Communicating Breakdown the SPM will have to handle some risks very carefully such as :
  • Wasting Times of Branch Managers and the Branch Employees of Grameen Bank
  • Money of Grameen Bank;
  • Avoiding Frustration for Communication Breakdown or not to show the Fraustration to the Bank or the people who are related with Grameen Bank
  • Avoiding to show the lack of Confidence to the Top to Bottom peoples who are engaged with Grameen Bank .

3. Communication Channels Calculation

formula = N(N-1) / 2;

where N= number of Stakeholders or responsible peoples

This section will depend on Point number 1

4. The Six demands for the Communication Plan needs :
  • Explanation : the Status, updates and the reports can be explained to the Executives
  • Purpose : The reasons of Good or Bad status can also be explained to the Executives
  • Frequency : The reporting should be Frequent and specific on monthly or year basis
  • Modality : Formats of project reports such as Paper Reports, or e-mail updates etc should be specified at the beginning
  • Duration : Duration is always very important for a company, specially for a huge Bank like Grameen Bank who has huge clients in 600 branches
  • Responsibility : Grameen Bank needs to know only the SPM as the one and only responsible person for the "Form 15" Project

5. Every Software Project manager should have a "Communication Responsibility Matrix"
  • This section will depend on point number 1. which will represent who will communicate with whom
  • also reminds for 5/10 minutes short meeting with different groups of stakeholders
  • Dealing Who needs what information
  • and be concerned about Who should not know What information as well

6. Predefined " When Communication is Needed with Whom " is very effective idea for a Software Project Manager
This section will also depend on point number 1. which will represent the date and time for communicate with
the in-house teams as well as Grameen Bank employees


7. For Formal Communications with the Grameen Bank Authority the SPM may use:
  • Power Point Presentation consists of reports / status / updates etc can be shown to the Authority of Grameen Bank.
  • Reports with Status and Quality Control can be presented for in-house
  • Conference call for both the in-house Teams as well as Authority of Grameen Bank
  • E-mail only with a reports, presentations and important attachments , nothing else to the Grameen Bank Authority

8. There are some types of Communication Modes which can be used for making Informal Communications with the Stakeholders. These are:
  • Quick E-mail if necessary only for in-house team members or individuals
  • Ad-hoc Meetings e.g. quick 2/3 minutes session with the in-house teams or the team players on lunch or at any brea
  • Instant Messaging using Chat boxes is good enough for status update report by a in-house team member
  • SMS can be used for reporting about the update status, it is very efficient if the two in-house people is out of reach from each other

9. For better Communication some Automating system can also be used for keeping the tracks of the Project status,
if the SPM have experiences on using these Project Servers, it can be very helpful, otherwise the SPM can keep the tracks with his own way


- Prepared by Muhammad Pasha