5 Warning Signs That A Project Is In Danger

From Georgina Laidlaw...

Here are the five warning signs that should have alerted me to the danger.

Warning Sign 1: Moving Away from the Agreed Plan

When I emailed my contact the copy his client had commissioned — a 30-second radio ad — and he had no amendments, I thought it was very odd. I’d included time for client amendments in my project estimate, which he’d approved. We’d also discussed the turnaround time for amendments, so we were both expecting that my ad copy wouldn’t be spot-on the first time.

When his only response to my submission of the draft ad was to ask me to send the invoice, I thought it was weird. Weirder still was that he emailed me this instruction: most of my clients will call to discuss draft copy. In an office, body language and behavior indicates clearly if a colleague is uncomfortable. But even email and phone conversations provide limited feedback.

What I should have done was called my contact immediately after I received his email to confirm that he and his client really had no amendments, and that both were happy to wrap the project up. But at the time I dismissed my unease, telling myself he was probably just busy.

Warning Sign 2: Unprecedented Behavior

No one I’ve ever worked with has accepted copy straight up, without amendments. Ever. So this should have been a huge red flag for me. If a person you’re working with does something you’ve never seen before — and their behavior affects you — check it out with them.

Before you do anything else, give them a call to get clarification about what’s going on. If their behavior has made you at all nervous or uneasy, let them know. By raising the topic, you give them the opportunity to talk about any issues they have — issues that, as in my contact’s case, they may otherwise be uncomfortable raising with you.

Warning Sign 3: Silence

A sudden silence can mean that your colleague has been called out of the office unexpectedly. Or it can mean that they have a problem that they don’t know how to discuss with you.

After I sent my 14-day invoice, I heard nothing from my client — not even an acknowledgment that he’d received it. Again, slightly uneasy, I reassured myself that he was probably busy. What I should have been doing was calling to follow up my invoice and make sure he’d received it.

As it turned out, when I called after the invoice due date and left a message, he didn’t respond. I emailed; no reply. When I called the following week, I was told he’d gone on leave for two weeks. When I was put through to Accounts, they told me there was a problem with the invoice and they’d been instructed not to pay it.

Warning Sign 4: Fast Talking

When I finally spoke to my contact, it was over the phone, and he told me that his client hadn’t liked the copy and they’d had to rewrite it. But he was going into a meeting and couldn’t talk now. He’d see that I “got paid at least part of the invoice,” and then he was gone.

By this time, I knew he wasn’t going to pay. I also knew he didn’t have a meeting. But there was still time to salvage things, had I wanted to. If this happened to me now, I’d ask to stop by the client’s office for ten minutes and discuss the problems with my work. Don’t let a client try to bamboozle you with fast talk or excuses — no matter how much they sugar-coat their story. Discussing the problems can also give you a chance to rectify the situation.

Warning Sign 5: General Unease

It won’t surprise you that all through this process I felt a general sense of unease — one that grew as matters progressed.

Now, whenever I get that feeling, I know I need to try to work out the cause of the discomfort. As my experience showed, it’s tempting to ignore your instincts and hope that things will go the way you’d like. No one likes to be uncomfortable, after all. But if you’re feeling it, you’re feeling it for a reason. Don’t ever ignore it!

7 Signs of Highly Effective Projects

1. Stakeholders are committed. Linking a bonus plan or incentive compensation to a project’s results can significantly increase the commitment level of the project’s sponsors and stakeholders.
   
2. Business benefits are realized.  Finance can help achieve this objective by tracking the project’s goals and the status of those goals as the project progresses. "You don’t want to be in a predicament where the good news is that we came in on budget, but the bad news is that the project doesn’t do what we want it to do," adds D’Andrea. Sometimes that means companies should pass on projects that don’t have a sound business case.
   
3. Work and schedule are predicted.  Anyone can blow the whistle on past-due or over-budget projects. But finance managers who can predict early whether a project is headed for trouble give project managers the chance to get back on course. PricewaterhouseCoopers has developed a status report in which key factors receive a green (good), yellow (possible trouble) or red (trouble) mark each time the project is monitored. Project managers list concerns and recommend actions for any factor that receives a yellow or red mark. For example, if work and schedule receive a yellow mark, a project manager might note that the rate of change requests from end users has doubled since the last status report. The project manager might recommend that the project team identify the root cause of the increase in change requests: Is it due to new market conditions or end users’ failure to clearly define their needs?
   
4. Scope is realistic and managed. Scope creep, the process through which a project mutates as functions are tacked on to the original plan, can destroy budgets. Finance managers should remind project managers of the financial impact associated with each additional piece of functionality they agree to implement once the project has begun.
   
5. Team is high-performing. D’Andrea says that morale, trust, physical environment, reward and recognition contribute to the healthy performance of the project team. He also notes that project managers should minimize unplanned turnover from their project teams to maintain high levels of productivity.
   
6. Risks are mitigated.  "If I were a CFO and somebody said, ‘We’re going to reinvent our business model by moving to the Web,’ I would want them to show me a feasibility test," says D’Andrea. "The best advice is: Don’t do something in a big way until you’ve seen it work in a small way."
   
7. Project team benefits are realized. Project teams are trying to enhance their reputation, add to their knowledge and skill sets, and develop staff with each project. If these aims are identified and satisfied, D’Andrea notes, the outlook for a project’s success is greater.

Source: PricewaterhouseCoopers

C++ On It's Way Out?

from www.daniweb.com

If you are a programmer than you probably know or at least know of C++. Well now a company called Digital Mars is developing the D programming lanugage.

"D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability."
Basically this programming language is looking to combine the best of all there is out there using features from C, C++, C#, and Java as well as Python and Ruby as the quote mentions above. You can view a whole comparison of the different languages here:
http://www.digitalmars.com/d/comparison.html

Programming languages are good for different things; C++ because its fast, Ruby because its simple, Java because its easy to learn. You hear a lot of stuff like that. So I really like the idea of combining the best of all these languages because it just means it will lead to better programs and more people will be able to learn how to program.

Project Management Proverbs

compiled and some written by Mike Harding Roberts

• It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women (although it is more fun trying). *
• The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.
• Any project can be estimated accurately (once it's completed).
• The most valuable and least used WORD in a project manager's vocabulary is "NO".
• The most valuable and least used PHRASE in a project manager's vocabulary is "I don't know".
• Nothing is impossible for the person who doesn't have to do it.
• You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.
• At the heart of every large project is a small project trying to get out.
• If you don't stand for something, you'll fall for anything.
• The more desperate the situation the more optimistic the situatee.
• If it looks like a duck, walks like a duck and quacks like a duck, it probably is a duck.
• Too few people on a project can't solve the problems - too many create more problems than they solve.
• A problem shared is a buck passed.
• A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.
• A user will tell you anything you ask about, but nothing more.
• A user is somebody who tells you what they want the day you give them what they asked for.
• Right answers to wrong questions are just as wrong as wrong answers to right questions.
• Of several possible interpretations of a communication, the least convenient is the correct one.
• What you don't know hurts you.
• The conditions attached to a promise are forgotten, only the promise is remembered.
• There's never enough time to do it right first time but there's always enough time to go back and do it again.
• I know that you believe that you understand what you think I said but I am not sure you realise that what you heard is not what I meant.
• Estimators do it in groups - bottom up and top down.
• Good estimators aren't modest: if it's huge they say so.
• The sooner you begin coding the later you finish.
• Anything that can be changed will be changed until there is no time left to change anything.
• If project content is allowed to change freely the rate of change will exceed the rate of progress.
• Change is inevitable - except from vending machines.
• The person who says it will take the longest and cost the most is the only one with a clue how to do the job.
• Difficult projects are easy, impossible projects are difficult, miracles are a little trickier.
• If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!
• The bitterness of poor quality lingers long after the sweetness of meeting the date is forgotten.
• If you're 6 months late on a milestone due next week but nevertheless really believe you can make it, you're a project manager.
• A verbal contract isn't worth the paper it's written on.
• What is not on paper has not been said.
• If you don't know where you're going, any road will take you there.
• If you fail to plan you are planning to fail.
• If you don't attack the risks, the risks will attack you.
• A little risk management saves a lot of fan cleaning.
• The sooner you get behind schedule, the more time you have to make it up.
• A badly planned project will take three times longer than expected - a well planned project only twice as long as expected.
• If you can keep your head while all about you are losing theirs, you haven't understood the plan.
• When all's said and done a lot more is said than done.
• If at first you don't succeed, remove all evidence you ever tried.
• Never put off until tomorrow what you can leave until the day after.
• Feather and down are padding - changes and contingencies will be real events.
• There are no good project managers - only lucky ones.
• The more you plan the luckier you get.

Project Management Tips for Successful Projects

Plan for Success

Your project management plan is your bible for success. Without it, there will not be a project because without a workable plan, you have no way to reach your goal. Your plan must start at with the goal that you want to achieve. Then, break down that go into workable segments. Set a timeline for each segment. Your team should know these timelines and adhere to them. This does not mean that you make a mad dash between segments. You want to allow enough time for these various stages to be achieved while still being able to meet the overall deadline. Remember, you can rework your plan to find better ways to get you where you need to be.

Key Performance Indicators (KPI)

Key performance indicators are those little segments that let you know you’re moving forward and moving towards achieving your goal. You want to set KPI’s that can be measured and realistically attained. Set your team up for success and not failure by constantly monitoring the key indicators. This can also be a benchmark tool to use on future projects to determine success. If you have been on a project that has failed then you know some of the KPI’s that should have been in place to have effectively evaluated the progress of the project. The easiest way to build KPI’s into your project is to put them into the schedule as critical tasks. That way you can track your performance indicators as part of your timeline. Its like a built in reminder system to check on the health of your project.

5 Key Factors for Project Success.
So how do you keep a project moving toward success?

1. Know exactly what your project is trying to achieve.
2. Plan effectively to reach your overall goal.
3. Keep open communications amongst team members.
4. Have a Q & A session at various stages to see if the plan needs to be revised to achieve the goal.
5. Motivate team members. After all, they are working hard to help you achieve the project’s goal.

Being a project manager is a lot of work. However, when you’ve see a project through to success, then it is all worth it. Success can “always” be attained if you have the proper plan in place, good communications between team members and flexibility to change the plan as needed –without compromising the timeline.

Top 10 Tips for Successful Software Development Management

by Jack Bicer

71% of the software projects do not succeed!

Here are some time tested guidelines that have been used extensively to deliver web

development projects successfully, on-time and on-budget. Although most of the

projects developed are between 1 to 10 man years of effort, these tips also scale nicely

for smaller projects of 2 man months to larger projects of 25 man years.

1. Understand the user’s needs, write the specs before coding and keep them up to date. Develop the User Interface with the specs and flush out design issues.
2. Break projects into modules of 1 week or shorter.
3. Implement risky modules early.
4. Create validation milestones, every 3 to 4 weeks.
5. Provide the necessary resources.
6. Get developer buy-in for features, timelines and milestones.
7. Keep people accountable to their commitments.
8. Resist “feature creep” during implementation and testing.
9. Use automated functional testing tools and do stress testing.
10. Under-promise, over-deliver and plan a pleasant surprise at the end.

In every project, one or more of these guidelines will be broken. A breach of a guideline does not mean a project will be unsuccessful. Other guidelines will usually pull you through and help the project succeed. It is the large number of breaches and the depth of the breaches that will create project failures.

Michael Greer - Ten Guaranteed Ways to Screw Up Any Project

1. Don’t bother prioritizing your organization’s overall project load. After all, if there’s a free-for-all approach to your overall program management (i.e., “survival of the fittest”), then the projects that survive will be those that were destined to survive. In the meantime, senior management need not trouble themselves aligning projects with strategic goals or facing the logical imperative that people simply cannot have 12 number one priorities! 
2. Encourage sponsors and key stakeholders to take a passive role on the project team. Let them assert their authority to reject deliverables at random, without participating in defining project outcomes in a high-resolution fashion. And above all, don’t bother project sponsors when their constituents (such as key SMEs and reviewers) drop the ball and miss their deadlines.
3. Set up ongoing committees focusing on management process (such as TQM groups, etc.) and make project team members participate in frequent meetings and write lots of reports… preferably when critical project deadlines are coming due.
4. Interrupt team members relentlessly … preferably during their time off. Find all sorts of trivial issues that “need to be addressed,” then keep their beepers and cell phones ringing and bury them in emails to keep them off balance.
5. Create a culture in which project managers are expected to “roll over” and take it when substantive new deliverables are added halfway through the project. (After all, only a tradesperson like a plumber or electrician would demand more money or more time for additional services; our people are “professionals” and should be prepared to be “flexible.”)
6. Half way through the project, when most of the deliverables have begun to take shape, add a whole bunch of previously unnamed stakeholders and ask them for their opinions about the project and its deliverables.
7. Encourage the sponsor to approve deliverables informally (with nods, smiles, and verbal praise); never force sponsors to stand behind their approvals with a formal sign-off. (In other words, give ‘em plenty of room to weasel out of agreements!)
8. Make sure project managers have lots of responsibilities and deadlines, but no authority whatsoever to acquire or remove people from the project; to get enough money, materials, or facilities; or insist on timely participation of SMEs and key reviewers.
9. Describe project deliverables in the vaguest possible terms so sponsors and reviewers have plenty of leeway to reinvent the project outputs repeatedly as the project unfolds.
10. Get projects up and running as quickly as possible – don’t worry about documenting agreements in a formal project charter, clearly describing team roles/responsibilities, or doing a thorough work breakdown analysis. After all, we know what we’re doing and we trust each other. So let’s get to it without a pesky audit trail!

Michael Greer's 14 Key Principles for Project Mgt. Success

This web-published article by Michael Greer is an excerpt from ” Handbook of Human Performance Technology, San Francisco, Jossey-Bass, 1999

1. Project managers must focus on three dimensions of project success.Simply put, project success means completing all project deliverables ontime, within budget, and to a level of quality that is acceptable to sponsors and stakeholders. The project manager must keep the team’s attention focused on achieving these broad goals.
2. Planning is everything — and ongoing. On one thing all PM texts and authorities agree: The single most important activity that project managers engage in is planning — detailed, systematic, team-involved plans are the only foundation for project success. And when real-world events conspire to change the plan, project managers must make a new one to reflect the changes. So planning and replanning must be a way of life for project managers.
3. Project managers must feel, and transmit to their team members, a sense of urgency. Because projects are finite endeavors with limited time, money, and other resources available, they must be kept moving toward completion. Since most team members have lots of other priorities, it’s up to the project manager to keep their attention on project deliverables and deadlines. Regular status checks, meetings, and reminders are essential.
4. Successful projects use a time-tested, proven project life cycle. We know what works. Models such as the standard ISD model and others described in this text can help ensure that professional standards and best practices are built into our project plans. Not only do these models typically support quality, they help to minimize rework. So when time or budget pressures seem to encourage taking short cuts, it’s up to the project manager to identify and defend the best project life cycle for the job.
5. All project deliverables and all project activities must be visualized and communicated in vivid detail. In short, the project manager and project team must early on create a tangible picture of the finished deliverables in the minds of everyone involved so that all effort is focused in the same direction. Avoid vague descriptions at all costs; spell it out, picture it, prototype it, and make sure everyone agrees to it.
6. Deliverables must evolve gradually, in successive approximations. It simply costs too much and risks too much time spent in rework to jump in with both feet and begin building all project deliverables. Build a little at a time, obtain incremental reviews and approvals, and maintain a controlled evolution.
7. Projects require clear approvals and sign-off by sponsors. Clear approval points, accompanied by formal sign-off by sponsors, SMEs, and other key stakeholders, should be demarcation points in the evolution of project deliverables. It’s this simple: anyone who has the power to reject or to demand revision of deliverables after they are complete must be required to examine and approve them as they are being built.
8. Project success is correlated with thorough analyses of the need for project deliverables. Our research has shown that when a project results in deliverables that are designed to meet a thoroughly documented need, then there is a greater likelihood of project success. So managers should insist that there is a documented business need for the project before they agree to consume organizational resources in completing it.
9. Project managers must fight for time to do things right. In our work with project managers we often hear this complaint: “We always seem to have time to do the project over; I just wish we had taken the time to do it right in the first place!” Projects must have available enough time to “do it right the first time.” And project managers must fight for this time by demonstrating to sponsors and top managers why it’s necessary and how time spent will result in quality deliverables.
10. Project manager responsibility must be matched by equivalent authority. It’s not enough to be held responsible for project outcomes; project managers must ask for and obtain enough authority to execute their responsibilities. Specifically, managers must have the authority to acquire and coordinate resources, request and receive SME cooperation, and make appropriate, binding decisions which have an impact on the success of the project.
11. Project sponsors and stakeholders must be active participants, not passive customers. Most project sponsors and stakeholders rightfully demand the authority to approve project deliverables, either wholly or in part. Along with this authority comes the responsibility to be an active participant in the early stages of the project (helping to define deliverables), to complete reviews of interim deliverables in a timely fashion (keeping the project moving), and to help expedite the project manager’s access to SMEs, members of the target audience, and essential documentation.
12. Projects typically must be sold, and resold. There are times when the project manager must function as salesperson to maintain the commitment of stakeholders and sponsors. With project plans in hand, project managers may need to periodically remind people about the business need that is being met and that their contributions are essential to help meet this need.
13. Project managers should acquire the best people they can and then do whatever it takes to keep the garbage out of their way. By acquiring the best people — the most skilled, the most experienced, the best qualified — the project manager can often compensate for too little time or money or other project constraints. Project managers should serve as an advocate for these valuable team members, helping to protect them from outside interruptions and helping them acquire the tools and working conditions necessary to apply their talents.
14. Top management must actively set priorities. In today’s leaner, self-managing organizations, it is not uncommon for project team members to be expected to play active roles on many project teams at the same time. Ultimately, there comes a time when resources are stretched to their limits and there are simply too many projects to be completed successfully. In response, some organizations have established a Project Office comprised of top managers from all departments to act as a clearinghouse for projects and project requests. The Project Office reviews the organization’s overall mission and strategies, establishes criteria for project selection and funding, monitors resource workloads, and determines which projects are of high enough priority to be approved. In this way top management provides the leadership necessary to prevent multi-project log jams. 

Programming: Object Oriented Design Tips

Here is an assortment of tips to keep in mind when using object oriented design in embedded systems:

1. Stay close to problem domain
2. Object discovery vs. object invention
3. Pick nouns or noun phrases as classes
4. Method names should contain a verb
5. Prefix adjectives when naming inheriting classes
6. Do not add suffixes to class names
7. Avoid one-to-one mapping from structured design
8. Replace multiple get-set methods with operations
9. Model classes that handle messages as state machines
10. Use const whenever possible
11. Restrict header file level dependency

Stay close to problem domain

Design is a process of modeling the problem domain into programming constructs. Object oriented design simplifies the design process by maintaining a one-to-one mapping between problem domain objects and software objects. To succeed in object oriented design, keep your design as close as possible to problem domain objects. The interactions between your objects should mirror interactions between corresponding problem domain objects.
Problem domain objects is basically an object that can be found in the problem itself. For example, when developing a text editor real-world objects would be, Paragraph, Sentence, Word, ScrollBar, TextSelection etc. While developing a call processing module, the objects might be Call, Ringer, ToneDetector, Subscriber etc.

Object discovery vs. object invention

The first step in object oriented analysis is to discover the objects that can be directly identified from the problem itself. In many cases objects can be identified  from the requirements. Objects discovered from the problem statement are extremely important. These objects will be the core objects in the design.
The next stage in object design is to "invent" objects. These objects are needed to "glue" together objects that have been identified during object discovery. Invented objects generally do not correspond to anything tangible in the problem domain. They are inventions of programmers to simplify design.
Consider the following statement from the requirements:
The circuit controller shall support digital and analog circuits. The circuit controller shall contain 32 DSPs. When the circuit controller receives a request to setup a circuit, it shall allocate a DSP to the circuit.
We discover the following objects from the requirement:

• CircuitController
• DigitalCircuit
• AnalogCircuit
• DSP

We invent the following objects based on our knowledge of the manager design pattern:

• DSPManager: Manages the 32 DSPs on the circuit controller
• CircuitManager: Manages the digital and analog circuits

We invent a Circuit base class for DigitalCircuit and AnalogCircuit by filtering properties that are common to DigitalCircuit and AnalogCircuit objects.
The relationship between the classes also follows from the requirement. CircuitController class contains DSPManager and CircuitManager classes. TheCircuitManager contains an array of Circuit class pointers. The DSPManager contains an array of DSP objects.

Pick nouns or noun phrases as classes

Identifying objects is easy, they should always be nouns. As we have seen in the Circuit Controller example, we picked up nouns from the requirements as classes in our design. Even when you invent classes, keep in mind that they should be nouns. Abstract concepts don't qualify as object names.
Naming the objects is extremely important in object oriented design. Chances are that if you name your object correctly, the designers and maintainers will assign it functionality that fits its name. Also note that, if you have trouble naming an object, you probably have the wrong object. At this point go back and look at the problem again and see if you can pick an alternative object.

Method names should contain verbs

In any language, actions performed by nouns are specified using verbs. Why should object oriented programming be any different? Thus make sure all the operation methods should contain verbs.
Thus the Circuit class we discussed earlier would have methods like:

• Activate
• Deactivate
• Block
• Unblock
• ChangeStatus

Notice that the methods do not include Circuit in the name (ActivateCircuit, BlockCircuit etc.) as being methods of Circuit its clear that they refer to operations on Circuit.

Prefix adjectives when naming inheriting classes

This one is fairly obvious. When a class inherits from a base class, the name for the new class can be determined just by prefixing it with the appropriate adjective. For example, classes inheriting from Circuit are called AnalogCircuit and DigitalCircuit. Following this convention leads to class names that convey information about the classes inheritance.

Do not add suffixes to class names

Do not add suffixes like Descriptor, ControlBlock, Agent to the class names. For example,  DigitalCircuit should not be called DigitalCircuitDescriptor or DigitalCircuitControlBlock. Such names are longer and do not convey the exact role of the class.

Avoid one-to-one mapping from structured design

Many developers moving from structured design just continue with structured design in C++. The classes developed correspond more to similar structured constructs they have used in the past. Similarity between C and C++ confuses developers. Make no mistake, object oriented programming is a completely different technique. The emphasis here is to keep the design process simple by minimizing the difference between the problem domain and software domain.

Replace multiple get-set methods with operations

Developers complain that after moving to object oriented programming, they spend considerable time writing mindless get and set methods. Here is a simple tip on reducing the get and set methods. Consider the code below:

Circuit Status (Multiple Get-Set)

void CircuitManager::GetStatus(const CircuitStatusMsg *pMsg) const { for (int i= 0; i < MAX_CIRCUITS; i++) { pMsg->circuitInfo[i].circuitId = m_pCircuit[i]->GetId(); pMsg->circuitInfo[i].circuitType = m_pCircuit[i]->GetType(); pMsg->circuitInfo[i].circuitStatus = m_pCircuit[i]->GetStatus(); pMsg->circuitInfo[i].circuitCallId = m_pCircuit[i]->GetCallId(); pMsg->circuitInfo[i].circuitState = m_pCircuit[i]->GetState(); } }

The above code can be replaced by moving the field filling in the message to the Circuit class. This way you do not need to define a large number of get operations. Also, any changes in the CircuitInfo field would result only in changes to the Circuit class. CircuitManager would be transparent as it does not look into CircuitInfo.

Circuit Status (Single Operation)

void CircuitManager::GetStatus(const CircuitStatusMsg *pMsg) const { for (int i= 0; i < MAX_CIRCUITS; i++) { m_pCircuit[i]->UpdateStatus(pMsg->circuitInfo[i]); } } void Circuit::UpdateStatus(CircuitInfo &circuitInfo) const { circuitInfo.circuitId = m_id; circuitInfo.circuitType = m_type; circuitInfo.circuitStatus = m_status; circuitInfo.circuitCallId = m_callId; circuitInfo.circuitState = m_state; }

Model classes that handle messages as state machines

Whenever you encounter a class that has to perform some level of message handling, its always better to model it as a state machine.

Use const whenever possible

C++ provides powerful support for const methods and fields. const should be used in the following cases:

• Methods that do not change the value of any variable in the class should be declared const methods.
• If a function is supposed to just read information from a class, pass a const pointer or reference to this function. The called function would be restricted to calling const methods and using the classes fields only on the right side of an expression.

Proper and consistent use of const will help you catch several bugs at compile time. So start using const from day one of your project.  If const is not used extensively from the beginning of a project, it will be close to impossible to add it later.

Restrict header file level dependency

Complex software requires a careful header file management even when programming in C. When developers move to C++, header file management becomes even more complex and time consuming. Reduce header file dependency by effective use of forward declarations in header files. Sometimes to reduce header file dependency you might have to change member variables from values to pointers. This might also warrant  changing inline functions to out-of-line functions. Every time you use a #include make sure that you have an extremely good reason to do so.

7 Steps to Project Success by Peter Draper

The successful completion of a big project should bring big benefits for your company - otherwise, why bother? The prize sought is often increased customer satisfaction, bigger profits, higher share price or some other key performance indicator. Projects often require company staff, experts and suppliers to come together on a temporary basis to carry out a one-off change that will leapfrog the company to greater success. But all too often, the hope of success meets with problems, delays and cost over-runs that cause frustration and stress for everyone concerned. The project that looked so good on the drawing board may somehow fail despite all seemingly reasonable efforts. So, what might be done to improve your project's chances of success?

Here is a seven step procedure that I use to manage successful projects. It guarantees the best chance of achieving maximum project benefits for my clients. This checklist should also be useful to senior company executives, functional chiefs and project managers alike. My procedural checklist keeps profits in mind as follows:

1. Profit from your project
2. Rally support
3. Organise plans, resources, etc
4. Focus on key benefits
5. Invoke risk responses in advance
6. Test your project is working
7. Switch to the new working practices

Step 1: Profit From Your Project

Think about it. Every part of every organisation needs to generate more benefit than it consumes. So, if your project, even on the drawing board, cannot produce profits for the company, then no amount of management effort further down the line is going to be help. I have seen many examples of proposed projects that have benefit to cost ratios that only barely meet the company investment hurdle rates. These benefits are also sometimes "inflated" using some proposed value of intangible items. If this is the case with your project, then maybe it is time to look deeper and consider other alternatives before you start. As the responsible executive, before you kick-off your project, I suggest you make sure that you have some good answers to the following questions:

• What is your company's business strategy?
• How will the outcome of this project add value to that strategy?
• What alternatives are there to doing this project?
• What dollar-value is this project outcome? (Get your finance staff to calculate internal rate of return, etc.)
• Is your project, in fact, mainly designed to avert some impending crisis?
• What contingency needs to be developed in the unlikely event that your project outcome may benefit from some additional support?

By considering the answers to these questions you should have most of the information required to justify the need, and hence, determine the expected benefits for your project. Select your project carefully.

Step 2: Rally Support

In addition to getting the top-level support from your executive management team, it is critical to rally support and get input from other interested parties too. For example, major customers may need to be consulted, as may representatives of the planned user base too.

These parties interested in the outcome of your project will:

• Contribute to your list of the benefits and also dis-benefits of the project
• Possess a wealth of expertise and experience for you to consult and gain valuable advice from
• Be the main candidates for providing funding or support for your project

The purpose of this step is to develop a clear picture of how your project will come together in more detail. The step is highly consultative and requires answers to the following questions:

• Has a similar project to this ever been done before? If so can this be used as a model?
• How could your project outcome be improved for the various interested parties?
• What legitimate concerns do the other interested parties have regarding your project?
• Are all parties in agreement with all the assumptions made?
• Should the order of magnitude costs and expected benefits be modified?
• What dependencies are there relating to other current projects?

Once these questions have been addressed you must check that the executive management team, major customers and other key parties are all on-board. They need to be aligned as much as possible to enable the required degree of collective ownership. Now you should have a great start to your project and a high degree of confidence that you will get those sought after benefits.

Step 3: Organise Plans, Resources, etc.

A key appointment on your project team is the project manager. He will take full and personal responsibility for achieving the successful outcome of your project using the best methods available. He organises everything. His starting point to getting the best resources, to negotiating the best contracts, to managing your project is to communicate effectively with all the relevant parties concerned. The key is to be communicating "facts" such as requirements and plans. He should be aware that communication is a two-way street and much of the time should be spent getting feedback and seeking information from knowledgeable parties.

The project manager is also an integrator. In particular, he integrates the project team and other interested parties, and he also integrates products and services. Any new product or service resulting from a project will need to be merged with the company infrastructure on "live" date. In building the project plan it is essential to break the work down into manageable units. However, in every area from technology to manufacturing to human resources there is currently an opportunity to leverage off standard models and structures. So ensure the project manager uses industry standards where possible, for example using:

• Process models (such as the Project Management Institute's project management methodology)
• Architecture models to enable "pick 'n' mix" type deliverables

It makes sense to consider outsourcing project activities and deliverables unless, say, for security reasons it must be in-house or perhaps it is somehow part of your core business.

Step 4: Focus on Key Benefits

Once the project has been planned, it is important to stay focused on key benefits. The problem is that projects tend to take on lives of their own. You cannot let this happen otherwise all sorts of side tracks may be taken or other features added in. It will probably be necessary to break up the project into smaller, independent sub-projects that are more easily manageable. These sub-projects must be:

• Small, that is, less than $1m
• Fast, that is, takes less than 6 months
• Compact, that is, fewer than 6 people on the team
• Focused on key benefits and not just deliverables

This is also the time to reconsider carefully again the desired project objective. Do these sub-projects really produce tangible added value in dollar amounts? It may be that considering the additional costs, many of these lesser features may be dropped to achieve project efficiency gains. Remember, jettison non-essentials and focus your project to do ONLY the items that MUST be done to achieve the benefits you really need.

Step 5: Invoke Risk Responses in Advance

During the life of your project the world is not standing still. Competitors are introducing changes, customers' demands are changing, technology is moving forward at near breakneck speed, etc. You cannot keep up with all this on your own. You must empower your project team to anticipate problems and you must tell them how you want them to deal with these issues in advance. Some studies show that up to 90% of project problems can be handled effectively by using proactive risk management similar to that described below. Here are the questions to ask:

• What problems have been encountered on similar projects in the past?
• What else can possibly go wrong at each stage of this project?
• What are the early warning signs of these problems occurring?
• What is the dollar impact of each possible problem that has been identified?
• What is the likelihood each problem might occur?
• What response strategy is best to handle each of these possible problems?

Evading the problem altogether is a good strategy for coping with risks, but alternatively, you might want to use one of the following standard risk responses:

• Avoidance - eliminating the cause
• Mitigation - reducing the effect
• Acceptance - simply accepting the impact
• Transference - "outsourcing" the problem

Managing project risks means anticipating them to avoid "fire-fighting" responses; and replacing them with prior delegated actions. This way your project outcome and benefits can be protected to a very large degree.

Step 6: Test Your Project is Working

Controlling your project involves testing and checking progress, then making adjustments to bring your project back on course. This means deciding up front what key measurements need to be taken and how often; and then deciding what values for these items make them unacceptable. Examples of such measures are:

• Work done (pay special attention to "scope creep")
• Cost variances
• Activities behind schedule
• Quality issues

These need to be considered on a "management by exception" basis and the facts need to be reported to interested parties. At the same time adjustments can be made to activities to bring these factors back into line immediately. This way, you can guide your project to a successful outcome. But be careful that watching paperwork alone is not enough. There will be critical times on any project when you must know how to motivate your team to achieve exceptional results.

Step 7: Switch to the New Working Practices

Congratulations! You have reached the final step. You now have to make sure you complete the last step to get those hard earned benefits. This generally requires switching off that out-going system, or re-deploying the department you have just made unnecessary, or simply stopping using that old set of procedures. To get the full project benefits, you need to switch to the new working practices completely. This final act often requires courage and resolve. I have come across many examples, say, of an old system that is never switched off because it is needed for that "special" client, or whole departments that continue in parallel years after a major company merger.

Of course, you should finally celebrate a job well done!

Peter Draper is an executive coach for project managers, globally via phone/email - providing systematic coaching support for already successful people. Further information available from www.linkedin.com/in/peterdraper 

Programming - Liberating The Bug

It's inevitable for programmers to run into a programming bug that is difficult to pin down. The most difficult are:

⁃ Time or Timing related: the bug only shows up at certain times, or based on other time-related events

⁃ Secondary or Tertiary: The bug only shows up when one or a series of other events occur

⁃ Hardware related: the bug only shows up when a hardware event occurs, such as an I2C event

I've seen programmers get lost trying to cause and track-down these kinds of bugs. In fact I managed a project that ran 2 months late because the programmer had a tertiary bug that he chased without telling anyone. OUCH!

There are tactics that can help deal with difficult bugs. I've used these to solve gnarly problems.

⁃ Isolate the problem code: separate the problem code out into a test program. This removes working code from debugging sessions.

⁃ Isolate hardware: When chasing a hardware related bug, remove extraneous hardware from the debugging environment. You don't need to be tracking serial port interrupts when fixing a video refresh bug.

⁃ Look for alternatives: after chasing a bug for a day or two, it's worth looking at coding alternatives. Can the problem code be rewritten taking a different tack? I recently had an RSS decode bug that I resolved by rewriting the code to look for a different header tag. Don't fight the dragon for too long.

Fighting bugs is part of the art of programming. How you deal with pesky bugs determines your ability to finish projects on time, or wallowing in lateness.

Project Management - Identify the Risks

A simple way to keep project from veering off schedule is to identify and plan for risks up front. I've joined countless projects that were running late because "something came up" that took the participants by surprise. It makes so much sense to plan for high risk tasks up front, but it isn't often done.

If your project relies on a new technology, set a strategy for dealing with technology risk. Is there an existing technology that can be substituted if the new technology does not meet expectations on schedule? Is there a way to test the new technology early in the project? Are there multiple tracks that can be used for implementing new and existing technologies?

Company or inter-company issues can be planned for as well. Are there end of quarter issues that could impact the project; and can you plan for them? Do you require something from another company in order to complete the project? Are there tasks that can be run in parallel while you wait for delivery?

Up front planning for risk can save a lot of headaches later in the project. It also make it much easier for a project manager running multiple projects. A little planning up front can go a long way.

Fed up with Comcast

Anyone else fed up with Comcast?

I've been a loyal customer for many years, but I've had enough. I developed cable set top box software, and as a result I have a collection of digital televisions. I have two televisions on HD DVR cable boxes, and two that are connected directly to the cable. Until November, Comcast broadcast their 2nd tier digital channels in the clear. This worked well for my two televisions connected directly to the cable. In November they began scrambling these channels, only leaving advertising and local channels in the clear.

I contacted Comcast Customer Support (oxymoron?) to see if I could remedy this situation without raising my already exorbitant $170+ monthly bill. The best they can come up with is a $10 savings, if I move my phone service to Comcast.

Alternatives? DirecTV and Dish TV both are offering attractive packages. A call to Dish shows that I can have at least the same level of programming, and all 4 TVs on HD DVRs for $70 per month. Hmm...

Use of Saline Nasal Irrigation Reviewed

So many people I know believe that irrigating with saline can help respiratory infections.

Use of Saline Nasal Irrigation Reviewed

via Medscape Medical News Headlines on 11/30/09

A review article offers guidance on use in the family practice setting of saline nasal irrigation for upper respiratory tract conditions.
Medscape Medical News

Posted via email from sapelzin's posterous

Sony's 3D TV Plans Become a Little Clearer

Sony's 3D TV Plans Become a Little Clearer

Posted using ShareThis

Untitled

A slap on the back is only a few inches away from a kick in the butt

via Ping.fm

Posted via web from sapelzin's posterous

Untitled

'Warning Stroke' Precedes 1 In 8 Strokes (http://ping.fm/tPZwh)

via Ping.fm

Posted via web from sapelzin's posterous

Untitled

Bones Weakened By Diabetes (http://ping.fm/hcsBU)

via Ping.fm

Posted via web from sapelzin's posterous

Eugene electric car makes its debut - Breaking News, Local News, Local Weather, Local Sports

Eugene electric car makes its debut - Breaking News, Local News, Local Weather, Local Sports

Posted using ShareThis

Spezzle: Drupal specifications that require less coding | Pronovix

Spezzle: Drupal specifications that require less coding

2009, July 10 - 08:19

Kristof Van Tomme

video:

Imagine: you are doing a project for a customer who doesn't know Drupal. Even before she contacted you, she made a bunch of wireframes and detailed specifications. That's a dream case right? Just one problem, all the user interfaces and features are just a little bit different from the way things are done in Drupal. This is one of the problems we want to address with Spezzle.

Spezzle is a planning tool that helps you and your customers make Drupal site specifications that will require minimal custom coding. The platform is intended to become a library of use cases and feature descriptions for Drupal sites that can be used also by people with little Drupal knowledge to compose a complete site description. But this site feature description is just the start, in the background a lot of meta data is added cause using RDFa the following other information is bundled with the feature descriptions:

• The implementation of the feature (e.g. what modules you can use and how you should configure them)
• You can create tickets straight from the specification overview.
• The documentation aspect means you can (re)use documentation that was put together before.
• You can markup parameters in the text that can be exported as settings (using the Drupal patterns module).

If that didn't get your attention let me say that we developed for the platform (and will contribute):

• An RDFa WYSIWYG editor
• An extension to faceted search that enables asynchronous searching in a block region
• Some Javascript goodness that dynamically builds a table of content form h-tags
• An RSS ticket exporter from the ticket RDFa properties
• Some extreme theming of the Drupal node edit form with JS tabs
• and much more...

Interested? Vote for our session at Drupalcon Paris.

Posted via email from sapelzin's posterous

Digital Customer in Health Care

Check out this SlideShare Presentation:

Digital Customer in Health Care

View more presentations from John Sharp.