Decision Support System for Project Management

Decision Support System

for

Project Management

Definition

Decision Support Systems (DSS) are a specific class of computerized information system that supports business and organizational decision-making activities. A properly-designed DSS is an interactive software-based system intended to help decision makers compile useful information from raw data, documents, personal knowledge, and/or business models to identify and solve problems and make decisions.

Taxonomies

As with the definition, there is no universally-accepted taxonomy of DSS either. Different authors propose different classifications. Using the relationship with the user as the criterion, Haettenschwiler differentiates passive, active, and cooperative DSS. A passive DSS is a system that aids the process of decision making, but that cannot bring out explicit decision suggestions or solutions. An active DSS can bring out such decision suggestions or solutions. A cooperative DSS allows the decision maker (or its advisor) to modify, complete, or refine the decision suggestions provided by the system, before sending them back to the system for validation. The system again improves, completes, and refines the suggestions of the decision maker and sends them back to her for validation. The whole process then starts again, until a consolidated solution is generated.

Using the mode of assistance as the criterion, Power differentiates communication-driven DSS, data-driven DSS, document-driven DSS, knowledge-driven DSS, and model-driven DSS.

A model-driven DSS emphasizes access to and manipulation of a statistical, financial, optimization, or simulation model. Model-driven DSS use data and parameters provided by users to assist decision makers in analyzing a situation; they are not necessarily data-intensive. Dicodess is an example of an open source model-driven DSS generator.

A communication-driven DSS supports more than one person working on a shared task; examples include integrated tools like Microsoft's NetMeeting or Groove.

A data-driven DSS or data-oriented DSS emphasizes access to and manipulation of a time series of internal company data and, sometimes, external data.

A document-driven DSS manages, retrieves, and manipulates unstructured information in a variety of electronic formats.

A knowledge-driven DSS provides specialized problem-solving expertise stored as facts, rules, procedures, or in similar structures.

Using scope as the criterion, Power differentiates enterprise-wide DSS and desktop DSS. An enterprise-wide DSS is linked to large data warehouses and serves many managers in the company. A desktop, single-user DSS is a small system that runs on an individual manager's PC.

Problem Identification

I Aldrin Thomas Gaine am working as Project Manager for software engineering projects. I wish, I could work better using DSS at my professional work. I feel a powerful DSS can help a project manager all the way he needs.

The Project Management Institute (PMI) defines a project as "a temporary endeavor undertaken to create a unique product or service". In most organizations projects are the preferred way of organizing work that is unique and different from ongoing operations. Project management is a special form of management. Project management is concerned with the application of general management practices to project management. Software engineering project management is a further refinement of project management practices to deal with the special challenges of managing a software engineering project.

There are many management works need to perform to manage a project like time management, cost management, quality management, human resource management, communication management, risk management, procurement management and so on.

Like a standard management process we can group all project management works in to four categories as;

1. Planning
   
2. Organizing
   
3. Leading
4. Controlling
   

A DSS can help the project manager to perform this entire task.

Proposed DSS

Software engineering projects are complex socio-technical systems whose behavior is the result of many technical and human factors, from personnel skills to development tools and processes to business goals. Project managers must identify the right combination of these factors to obtain the desired results. In many fields, managers get support from sophisticated decision support systems, but these haven't yet entered the software engineering mainstream. A hybrid modeling approach can quickly produce process models that can provide project managers accurate predictions, help them design the desired project route, and validate process changes.

Here, I am proposing a hybrid DSS, which will be a combination of different type of DSS like; document-driven, data-driven, communication-driven and knowledge-driven DSS. This system will take decision by its processing ways along with human interaction. In the other hand, the decision will be taken by a combination of DSS and human brainstorming.

Figure : Model Diagram of the Proposed DSS

The system will work on all entities of a software engineering project. Following is the list of relevant entities of the proposed model.

Entities of the model;

1. Client
   
2. Management Body
   
3. Project Manager
   
4. Systems Analyst
   
5. Software Architect / Designer
   
6. Programmer / Coder
   
7. Quality Assurance Engineer
   
8. Implementer

The process of this model will be a combination of few sub-DSSs. This includes document-driven, data-driven, communication-driven and knowledge-driven as follows;

1. Planning : Document Driven, Knowledge- Driven and Communication Driven
   
2. Organizing : Data Driven and Document Driven
   
3. Leading : Knowledge Driven
   
4. Controlling : Data Driven
   

Apparently, it seems that project management is a routine work but it's not true all time. There are many peculiarities in a project and they differ from project to project. Document and data of one project helps to execute another project. A project planning is always new. People makes plan based on experience, existing documents, knowledge and communication with clients.

Organizing is a skill of the Project Manger. Here the DSS will work Data and Document to make support the PM to make a decision.

Leading require technical knowledge (for software engineering) as well as motivating skill. Here the DSS will work on knowledge to make proper decision.

Controlling is the decision on monitoring data. The system will capture monitoring data to make decision and so on.

Advantages of the DSS

• Improves personal efficiency: By using the DSS, personal efficiency of the Project Manager will be improved.
  
• Expedites problem solving: Problem solving time will be reduced in many ways.
  
• Facilitates interpersonal communication: All entities of the system will be facilitated to build and improve their interpersonal communication and communication skills.
  
• Promotes learning or training: A successful use of a decision support system requires training and for that a DSS promotes learning or training in a way.
  
• Increases organizational control: Through the use of this system organization control will be increased.
  
• Generates new evidence in support of a decision: This DSS will work on various sub-types of DSS like data-driven, document driven etc. Based on these a decision will be taken, so there are always evidence of the decision will be kept for future reference.
  
• Creates a competitive advantage over competition: Collection of above advantages will work for create competitive advantages over competition for the organization. This will help the organization to grow for the market.
  

Feasibility

Site Readiness: Now-a-days, almost all project manager use computers for performing their day to day activities. They have the know-how to use computer systems. For the reason it is very much feasible to co-opt a new decision support syste.

Technical Feasibility: The proposed model is very much suitable to convert it to computer based decision support system. This will not require any additional technical resources to be implemented. Resources of a small office or home office (SOHO) will be sufficient to implement the system.

Financial Feasibility: To develop any system this system will also involve financial expenses. But at the same time early-mentioned advantages will reduce the cost of long run.

Drawbacks

Now-a-days, even in Bangladesh, offices are equipped with latest models computers, faster LANs and also computer literate people. Some drawbacks of the system like good network, skilled personnel are already eliminated by the offices' technical environment. But it must be mentioned here that the security measure must be taken for the system which could be a drawback for some organization regarding the cost factor.

Summary

Decision support systems combine individuals' and computers' capabilities to improve the quality of decisions. Usually adopted in manufacturing to design floor plans and optimize resource allocation and performance, DSSs are penetrating increasingly complex application areas, from insurance fraud detection to military system procurement to emergency planning. Although researchers have suggested many approaches, DSSs haven't yet entered the main stream of software engineering tools. The complexity of the software process and its socio-technical nature are often mentioned as the main obstacles to their adoption. As DSSs are developed for other equally complex application areas, we need to identify approaches that can overcome these difficulties and enable project managers to exploit DSSs' capabilities in their daily activities. A hybrid two-level modeling approach is a step in this direction.

Deepro's Finger Treatment - III

After re-draining all pusses by making a hole at his finger the Doc bandaged in once again. At the next day we went there for dressing. The Doc said now it is improving and it doesn’t need bandage or dressing again. He advised to keep it clean and save from any pressure or hurt on it.

Then it was on the way to be cured. The nail of the finger has gone out. Still it is not fully recovered. We hope it will be fully cured within another one or two months.

Deepro’s Finger Treatment – II

Today was the scheduled day for the final work for his finger treatment. After four days of dressing we went the renowned hospital to meet the doctor (who did the surgery) once again. By the way, all four dressings were made by different people other than the doctor.

 

We (me & my wife) were hopeful to close the hospital transaction today. After completing all payments in advance, we were waiting there this morning, starting ten minutes before the scheduled time. Within half an hour of schedules time (it was 10:15 am) we asked several times to the nurses at nurse’s station regarding the doctor we are waiting for whom. One thing we must have to disclose that we didn’t find any time management in the hospital. Everyday, we had to wait for doctor, nurses even medicine and food for the patient while he was admitted and under treatment of IPD.

 

After a long wait the doctor came. Removed the bandage and said there are more infections at the finger and past four dressing was wrong. Here we can recall that; we went to the doctor for treatment of infection. He made the surgical operation and after four days there are still the infections alive. Now what?

 

I am not a doctor even I don’t know anything about medical but I can hope for development after a surgical operation. Now, I have doubt; about the standard of medical services we have received from the hospital. The question is, these all was happened about a small medical case, then what about vital cases like cancer, tuberculosis etc.?

Deepro’s Finger Treatment

It was a small infection of Deepro’s index/pointing finger of his right hand. He is my only son; six years old. We went to doctors and hospitals to get medical treatment for him. It was a bad experience.

 

The infection was getting bigger day by day. We went to some local physician (child specialist) for his medical treatment. The doctor prescribed to have some anti-biotic treatment with some prediction to be cured soon.

 

Within the scheduled time it was not cured. Then the doc advised again to take him to a child surgery specialist to drain all pusses by surgical operation.

 

As per his advice we went to a renowned hospital and got admitted their.  Got treatment their and hope it will work and he will be cured within a week.

 

This is a general story of all general people. What I wrote above is from the positive view point. As the doctors and hospitals still working for people I salute them. But most of the cases, the doctors are not working for people they working for themselves. They are making money by private practice. Nurses and admin people of hospitals are not making money so far I know. They are just damn care about their duties like anything. Especially, nurses are very irresponsive.

 

We took the treatment from one of two international standard hospitals in our country. They are fully equipped with good doctors, latest apparatuses, information systems etc. So far I found doctors are quite okay and responsive. All others are bullshit. At an emergency time I pressed the ‘nurse presence’ button but no one came. I went out from the cabin and gone to the nurse station. I found two nurses are busy with gossiping where as there is one monitor showing my call, nurse presence requires at room number 123.

 

I have very bad experience with doctors and nurses.  My son lost some of his nervous system in his brain by their damn care ness. That is the real tragic story.  So, I thank them this time they worked for us by making us panic and puzzled.

 

(I didn’t talk about their fees and charges. Obviously, it was high. Without it, how will they make money?)

HOW TO BE A SUCCESSFUL PM

HOW TO BE A SUCCESSFUL PROJECT MANAGER

The Project Manager

There is more to being a successful Project Manager than being an expert in MS Project. Giving someone a recipe book does not make that person a gourmet chef. Nor does giving someone a word processor make that person an author. There are certain obvious things that every good Project Manager knows and follows. However, what makes a Project Manager really successful is adherence to a number of additional common-sense items which can easily be overlooked. Some of these 'little' things are in fact the vital elements of successful project management. This document is a summary of50 of these 'little' things. The intention is that a Project Manager should refer to these 50 points on a regular basis to help to remain focused on the real issues of successful project management.

1. PROJECTS

1. A project is not a project unless it has four key elements. These elements are :

• An Objective and Scope (What is the project designed to achieve?)
  
• A deadline (By when is it required to complete the project?)
  
• Available Resources (both people and equipment)
  
• Agreed Budget (signed off by the client)
  

If you are asked to accept total responsibility for a project you should make sure that these four elements are all in place.

2. Treat your time as if someone is paying for it -someone is.

3. lt is essential to distinguish between what is important and what is urgent.

4. Being good is important; being trusted is essential.

5. When a decision is required, make a decision. No one is right 100% of the time so do not afraid to make a a wrong decision. Deliberately not deciding is a decision too.

6. Don't make promises you can't keep.

7. Never break a promise.

8. Always have your documents proof-read. Never send out documents, memos, etc. containing spelling errors, grammar errors or typos. Do not rely on the spelling and grammar checkers contained in popular word processing software packages.

9. Direct memos or e-mail only to the person for whom the message is intended. The other people who need to know can be copied on the message. A message should only be addressed to more than one person if it is expected that more than one person is to take action from the message.

10. Always return telephone cans and answer correspondence as soon as possible.

11. Don't wait until the last minute to follow up people on the action points they have been assigned. If you find out that they are not doing the expected task and there is no time left to pursue an alternative course of action, the project time schedule will be affected.

12. Project Managers who rely on paperwork to report activities are bound to fail.

13. There is no such thing as too much allowance for contingency. Nothing ever goes to plan.

14. Maintain a sense of humor and use it where appropriate. It can be especially useful to defuse tense situations.

2. CLIENTS

15. Always treat the client as king, even if no-one else in your organization does.

16. Always know what is important to your client and what is only of importance to you.

17. Always tell the truth to a client. If something has gone off the tracks, say so.

18. If the client asks you something and you do not know the answer, do not be afraid to say so. Nobody expects anybody to know the answer to everything. However it is important to make an undertaking to the client that you will seek out the answer.

19. If it becomes obvious that a deadline in the project will not be met, let the client know as soon as possible. Bad news now will not be as damaging to the client relationship as bad news later on.

20. Never appear stressed in front of a client, a customer or your management. Ask yourself if the matter at hand is really all that important in the scheme of human events.

21. Your final presentation or recommendations to a client should never come as a surprise to that client. You should go through a continuous process of previewing intended results with the client.

22. Always be aware of who would replace your client if the client was no longer associated with the project.

23. Try to keep up a close relationship with these possible replacement personnel as well as with the client.

3. PEOPLE

24. Learn to remember other people's names. Always spell people's names correctly.

25. Treat everyone on the project with respect and dignity. Don't ever be patronizing.

26. Always remember to say thank you to anyone who helps out on a project. This applies to major contributions of work as equally as to minor efforts.

27. Share the credit for successful projects and make sure that the supervisor or manager of each project participant is aware of the relevant person's contribution.

28. Don't criticize other people's ideas unless you can come up with something better.

29. Never correct or admonish a colleague in front of a client.

4. YOUR MANAGER/BOSS

30. Be aware of the details of your job description but never be restricted by it. Do whatever needs to be done.

31. Do not feel compelled to take on work which you consider to be outside the agreed scope of the project. If it is a minor additional task you should agree to do it in order to keep the client satisfied. If the task is of sufficient magnitude to affect the project time schedule it should be form part of a variation agreement.

32. Never take a problem to your manager without some possible solutions. You are getting paid to think, not to complain or criticize.

33. Do not work long hours than necessary. It is the quality of the work that counts, not the quantity.

34. Always complete and present timesheet and invoices on time.

5. SIMPLIFICATION

35. Keep documents simple. God told to Prophet Moses Ten Commandments to lay down the rules for all human civilization. You do not need 100 pages to layout a strategy which no-one is likely to read anyway.

36. Try to reduce all results of analysis to three bullet points. Few people will take the time to read, let alone understand, any more than three points.

37. It is unlikely that any client will read a GANTT chart which runs over more than two pages. Keep longer charts for your own use, if necessary, but do not present them to a client.

38. Never put more than about 36 words on an overhead slide. Use graphics. Don't show slides containing columns of numbers.

6. MEETINGS

39. Never attend a meeting unless you know what the intended objective of the meeting is. Never go into a meeting without planning beforehand what you intend to get out of it.

40. A working meeting has about six people attending. Meetings larger than this are generally for information transfer.

41. Learn how to prepare a meeting agenda.

42. Don't be late for meetings. If you do happen to be late don't make it a big deal- just apologize.

43. Never go into a meeting without your diary.

44. Learn how to chair a meeting.

45. Learn how to chair a teleconference. At the start of the teleconference each participant should introduce himself/herself and give a job title if appropriate.

• Always start with locations at the other end of the telephone. Use the name of a participant preceding each directed question or statement. 
  
• Always defer the floor to people at the other end of the telephone if there is competition to be the next speaker. 
  
• Be prepared to repeat comments for everybody's benefit when it is not obvious that everyone heard the comment. Ensure people do not engage in conversational asides.
  

46. Learn to take minutes and chair simultaneously. Choose someone else to chair the meeting if it is more appropriate. Always try to keep control of the minutes; control of the minutes (especially the action points in the minutes} often equates to control of the project itself.

47. Ensure that when action points are agreed at a meeting you also include who is to carry out the action and the date by when the action is to be carried out.

48. Always put the time and place for the next meeting on the bottom of the minutes of a previous meeting.

49. Make sure the minutes of a meeting are distributed as soon as possible after a meeting.

7. CONCLUSION

50. At the end of a project always conduct a post-implementation review (PIR) and document the outcomes. It is said that those who ignore the lessons of history are fated to repeat those errors.


A PROJECT MANAGER ACCEPTS THINGS THAT CAN NOT CHANGE HAS THE COURAGE TO CHANGE THINGS THAT CAN AND HAS THE WISDOM TO HIDE THE BODIES OF THE PEOPLE KILLED BECAUSE THEY GOT IN THE WAY.


PREPARED BY: MUHAMMAD MUNIR, INSTRUCTOR
SOURCE: FROM PERSONAL EXPERIENCE AND NOTES FROM A RENOWNED PROJECT MANAGER, IAIN MESSER.

(This document was given to me by the author Muhammad Munir. He was my teacher of ‘System Analysis & Design’ while I was studying MBA. I am very grateful to him.)

SCRAPPY PROJECT MANAGEMENT

SCRAPPY PROJECT MANAGEMENT
Project Management Dialogues with ATTITUDE!

by Kimberly M. Wiefling, M.S.


This Month's Featured Noggin' Floggin':
Being a Great Project Leader with a Mortgage and Kids in College

One of the strong beliefs that I have about effective project leadership is that it cannot be done by someone who has a mortgage, kids in college, or a spouse who doesn't work. I don't have kids, my spouse does work, and I am totally open to living in my car, if necessary. In my experience, a project leader must often operate in an environment where the very people who sign their paychecks are also the biggest obstacles to success. That's why I developed Scrappy Project Management, a take-no-prisoners approach to getting the job done no matter what, with little or no regard for your own professional future beyond the end of the project.

But some people have asked what can be done if they DO rely on their job for the little niceties of life, like food, shelter, electricity and running water. And even I admit that my perspective is rather polarized—even cynical. There are some perfectly effective project managers who manage to maintain good working relationships with uncooperative executives, vendors, team members and customers. After deep reflection on the matter, I am forced to admit that tact and diplomacy, while somewhat time consuming, may still have a place in the project leader's toolkit.

Turn Down the Heat!

The environment surrounding a project can be a real pressure cooker. And the commitment of some project managers is so great that they take on a burden greater than any normal human being can carry. Whatever tact and diplomacy they brought into the situation can suffer under the crushing weight of ultimate responsibility for a project that seems, if only momentarily, to matter more than life itself. This could be due to the poor judgment on the part of the leader who doesn't know their own limits, lack of personal maturity, or stunted growth in the emotional intelligence department. Or it could simply be an act of self-deception, using the urgency of project goals as a means for justifying thoughtless behavior or needlessly cruel acts. That's what I concluded when I took a good hard look at some of my own behavior in my early days.

One of the biggest mistakes made as a novice project manager was burning bridges that I would later need to walk across. Heck, I was a friggin' arsonist! If someone on my team didn't do their action item, I'd chew their behind and then came back and do it again before it even had a chance to heal.

Nothing sticks in my mind so clearly as the day I told the VP of Engineering the he was the #2 biggest risk to our success, and taunted him into asking "What's the #1 biggest risk?" I was only too happy to tell him it was our CEO. These well-meaning execs would pop in and ask about status, interrupting the work of the person on the critical path, and then lob out the dreaded "What would it take to add this teensy weensy little feature to this revision?" What a change management nightmare! Try putting THAT into your schedule! I even went so far as to put up a sign on the door of a critical design engineer basically saying "Hey, you – CEO and VP of Engineering guys – STAY OUT of this office!"

My extreme measures did manage to keep these meddlers out of our way long enough to ship the product on schedule in spite of ridiculous deadlines and impossible requests from a customer I couldn't intimidate as easily. But my feet got pretty scorched walking over the flaming hot coals of the bridges that I burned as I came to need the cooperation of these unfortunate souls at some future date.

No Jerks Allowed

It's a small world, and the relationships forged in our work will outlast the projects, maybe even the companies. According to Dr. Robert Sutton of the Stanford Graduate School of Business, and the author of The No Asshole Rule, acting like a jerk, even for a worthy cause, is now officially banned in some companies. First published as an article for the Harvard Business Review, there's now even a test to see how much of an asshole you are. (I'll send a free autographed copy of my book to the first 10 people to correctly guess my score. Just send an email to kimberly@wiefling.com with your estimate. Two significant figures to the left of the decimal only, please! No need to get down to tenths of a percent, you engineering guys.)

I can think of very few projects worth destroying valuable relationships over. OK, maybe if you're trying to end human stupidity, stop global warming, or bring back the 60's. But for the most part, I've regretted sacrificing relationships to hardware and software milestones. Yes, we need to be determined. Yes, we need to be persistent, even relentless. But, as one person who was unlucky enough to be my boss during this era said, "There's a difference between scratching your rear and ripping it to pieces!"

The "And" Stance

So, what if you are 100% absolutely committed to successfully achieve the goals of the project but there are uncooperative people whose behavior flies in the face of reason, good judgment and common sense? You don't have to choose between "effective project leadership" or "effective working relationships". In fact, one supports the other. Without effective working relationships we won't have the necessary buy-in and support that we need to succeed; and the moment we turn our backs we'll find a knife in it, or the action stops altogether. We simply must find ways to achieve both successful results and successful relationships. Instead of either/or thinking, we need to take what the Harvard Negotiation Project (HNP) calls the "AND" stance.

As project managers, we are nothing if not the world's most active negotiators, using influence rather than direct authority to obtain resources, build commitment, and reach agreement in every aspect of our work. Influencing without authority is the essence of negotiation, and every project leader needs to learn the essentials of negotiation in order to reduce the temptation to resort to more destructive ways to achieve frequently fleeting results. HNP is best known for developing the theory of "principled negotiation", which is thoroughly discussed in a real jewel of a book called Getting to YES: Negotiating Agreement Without Giving In. Although this book was published more than 25 years ago, it is still completely relevant and a very worthwhile read. Even better, listen to the audio recording while stuck in traffic. The principled negotiation approach can be summed up as "letting the other guy have your way", and consists of the following four guidelines:

1. PEOPLE: Separate the People from the Problem. Don't let your personal dislike of someone's style, manner or opinions become an obstacle to your success. Attack issues together, rather than each other. Stay focused on jointly solving the problem, and keep your negative personal opinions about others to yourself. As a leader you no longer have the luxury of gossiping.
2. INTERESTS: Focus on Interests not Positions. Most people fall immediately into advocating for their positions and then struggling to convince the other person of the correctness of their view. Rarely do people take the time to dig beneath the surface to discover the interests behind their positions. What ensues is often no more creative than offering to "split the difference", leaving untold possibilities undiscovered.
3. OPTIONS: Generate Options for Mutual Gain before Choosing. There's a real temptation to argue over two choices instead of generating a third. Peeking behind positions to the interests motivating them can reveal a world of possibilities better than either initial proposal. If you really want to expand what's possible, insist on generating at least two or three additional ideas before coming to agreement. This process reduces the chances that either you or your colleague will stubbornly stick to your initial views.
4. OBJECTIVE CRITERIA: Avoid a bitter contest of wills by using objective standards to make decisions. Review the actual performance of past projects to resolve differences of opinion about schedule and budget. Refer to industry standards rather than bull-headed insistence that someone trust you because you know better.

In addition to using principled negotiation, you might also benefit from including the quality of your relationships among your goals for the project (See Geof Lory's recent column for a more extensive discussion of this.) Or try imagining for a few minutes that the other person is just as committed to you to the project success but has a different way of showing it. Oh, and get a little more sleep so you're not so exhausted! It's a lot easier to be patient when you're not sleep deprived. Using your powerful influencing skills will result in you being considered intelligent, experienced, confident and reasonable. You may even find that you rather enjoy embracing adversaries in the dance of diplomacy, instead of acting like a jerk.

Your reputation for how you treat people will follow you, and will take years to change even after you make changes in your behavior. Although I'm still willing to trade results for relationships in certain situations, I'm much more likely to search for more mutually agreeable ways to achieve ridiculous goals on impossible projects. After all, it's a very small planet.

 

Information Radiators (test post)

Information Radiators

 

An information radiator is a large display of critical team information that is continuously updated and located in a spot where the team can see it constantly. The term "information radiator" 

was introduced extensively with a solid theoretical framework in Agile Software Development by Alistair Cockburn.

Information radiators are typically used to display the state of work packages, the condition of tests or the progress of the team. Team members are usually free to update the 

information radiator. Some information radiators may have rules about how they are updated.

Whiteboards, flip charts, poster boards or large electronic displays can all be used as the base media for an information radiator. For teams new to adopting agile work practices the best medium is usually a poster board on the wall with index cards and push pins. The index cards have a small amount of information on each of them and the push pins allow them to be moved around.

Information radiators help amplify feedback, empower teams and focus a team on work results. Too many information radiators become confusing to understand and cumbersome to maintain. If an information radiator is not being updated it should be reconsidered and either changed or discarded.

Here is an information radiator used to quickly display the status of multiple projects to an agile Project Management Office:

 

As the team used an information radiator, it can adapt the display of information to become more appropriate to the way the team is operating and the information they are really concerned about. For example, on the above IR for a PMO, the group may decide that they wish to put red dots on projects that are in trouble in some way.

 

Source: www.agileadvice.com