Search This Blog

Tuesday, April 13, 2010

Danger! Danger! The Warning Signs of a Failing Project by Ty Kiisel



As a kid I loved the Lost in Space TV series.  The story, an adaptation of the Swiss Family Robinson, features a 1997 version of the Robinson family on a mission to colonize a planet near the star, Alpha Centauri.  Selected from among two million volunteers for the mission, the Robinsons, their pilot, and their B-9 environmental robot crash land on an unnamed planet after sabotage disables their spacecraft, the Jupiter 2.
The youngest member of the crew, 9-year old Will Robinson, and the robot become companions and playmates on the planet.  Warning Will and the Robinsons of impending danger, the robot's cry of "Danger! Danger!" usually meant something exciting was about to happen.

Although most projects don't have a B-9 robot, there are warning signs that identify a troubled project early enough to do something about it.

The earliest signs that a project is in trouble are hard to measure objectively, but are relatively easy to spot, if you're watching:
  1. Lack of interest: Whether it's a lack of interest within the project team or among project stake holders, it's often demonstrated by people not showing up for meetings, a lack of active participation and feedback, or a poorly energized user base.  This is an early-warning sign of a project in trouble.
  2. Poor communication: If nobody is communicating, including stakeholders, team members, and end users, there could be a problem.
  3. Lack of velocity: Projects should always be moving forward.  The best way to keep a good velocity is to divide your project into small deliverables at frequent intervals.  If the project isn't moving forward, it's likely in trouble.
  4. A "no-bad-news" environment: Nobody likes to be the bearer of bad news, but sometimes organizations need to face the reality of negative news.  This includes project team members who don't want to be the messenger and business leaders who tend to shoot the messenger. If there is not an environment where the communication is honest about "reality," projects tend to fail.
Intangible signals aren't the only indicators that a project is in trouble, there are a number of measurable signs as well:
  1. Lots of overtime: A project running on schedule should have little or no overtime.  Overtime is often a quick fix, but leads to poor employee health resulting from too much caffeine, too many late nights, and too much junk food.  (It also leads to mistakes.)
  2. Diversion of resources: When people are pulled from one project to work on something else it could be a sign of trouble.  If you've budgeted your human resources properly, a few hours here and there on a troubled project can quickly add up and cascade down, endangering healthy projects.
  3. Ratios trouble: Cost ratios and schedule ratios are financial metrics that allow business leaders to measure budgeted time and money verses money and time actually spent.  Without metrics, all you have to rely on is the accuracy of the communication you receive from project teams.
  4. Milestones aren't met: This is pretty obvious, but it is surprising how many times this warning sign is ignored.  Small, discrete, and often, are the guidelines for the milestones of a successful project.
  5. Scope changes: A common approach to shoring up a lagging project is to change the scope.  Eliminating features or relaxing requirements is not uncommon, but if project teams are doing it because the project is in trouble, it's a huge warning sign of danger ahead.
Of course, warning signs are not the work management harbinger of doom, they are just warning signs that a project might be in trouble.  Depending on how your organization handles project based work, the right project management tools can help identify potential issues early, when there's still time to do something about them.

How do you spot struggling projects early—when there's still time to take action?

Friday, April 9, 2010

Four Early Warning Signs of a Project in Trouble, by Ty Kiisel




Underground mining is a dangerous occupation.  What's more, before the advent of sophisticated breathing apparatus, methane and carbon monoxide made it even more dangerous for the men working in the mines.  In the early days of underground mining, because their metabolism was susceptible to methane and carbon monoxide poisoning, canaries played an important role in keeping miners safe.
  1. They provided an audible warning: Canaries typically sing most of the time—when they stopped singing, it was a warning sign that they were being overcome by the toxic gas
  2. They provided a visual warning: When they started to sway and fall from their perch, it was a signal that they were succumbing to the poison gas.
Miners who paid attention to the early warning signs owed their lives to the canaries—they were able to recognize the danger and get out of the mine before it was too late.

I think everyone would agree that missing deadlines or exceeding budgets is evidence that a project is probably in trouble.  However, those symptoms are often recognized after it's too late to do anything about it.  Anyone doing project based work knows how important it is to recognize a project in trouble before it's too late.  Not too long ago, I came across this list of early warning signs that every project manager should be aware of:
  1. Direction from management is either missing or inconsistent: The only thing worse than project leadership that is missing in action, is direction that contradicts itself and changes frequently.
  2. Business management and project management aren't on the same page:  If the project gets consistent direction, but it's at odds with company business objectives, there is more than likely a problem.
  3. Project goals are not clearly articulated and understood by the project team:  Although every project usually has a business goal or two—projects without a business objective should probably be reconsidered, right?—often those goals aren't clearly articulated or understood by the project team.  Occasionally, the business objective is thought to be so obvious it's never clearly stated.  Unfortunately this could lead to misunderstanding and inconsistent presumptions about priorities.
  4. Team members don't communicate with each other:  Sometimes, even teams that get along well don't communicate well. Communication and collaboration are essential to any successful project.
Recognizing problems before it's too late to do anything about them is critical to work management success.  Addressing issues early is the best way to save a lagging project, as well as a project manager's career.  What early warning signs to do you watch for?

Monday, April 5, 2010

Tips to Increase Software Development Efficiency - by TLoop

If you are a software developer then you know that your job can be both frustrating and rewarding. Even though it can take many hours and various processes to complete, in the end you know that the software will be just right and work seamlessly. All the hard hours of work will pay off. Remember to follow some simple guidelines to help make your job easier and assist you with the development of your software.

It's important to care about what you do. If you don't then the end product will not showcase your best skills and/or abilities. The software will probably not perform as seamlessly as your would expect. If you feel like you are in a slump as a software developer then step back and re-assess your profession. Maybe you need to change focuses or try to learn something knew so you don't feel like you are performing the same tasks day-in and day-out.

Remember to provide options to your clients. If you are not sure how something can be done try to see if you can learn how to perform certain functions. Over time you will add a new skill set to your tool belt and help grow your knowledge base. Software development is always changing and staying on-top of these changes will only continue to help you.

Create contracts that help protect yourself. You want to make sure that you provide clients with software that meets the outlined expectations, no more and no less. Having a contract that is highly specialized and specific will help you keep your development within the scope of the project. If you don't have a project scope, you may be spending too much time of the project and limiting your revenue growth.

It's increasingly paramount to think about your work. Over time you will develop certain business practices, do these practices hinder your performance or make you more efficient? Outlining and reviewing how you conduct business and develop software is a great way to access factors that can help you with your job.

Take the time to access your performance and review ways that can help your increase your efficiency during the software development process. Overtime you will develop effective and efficient software development practices that help generate fully functioning and powerful software.

Wednesday, March 24, 2010

The Future of Project Management - Stacy A. Goff


Today's information technology organizations are responding to the most treacherous recession in memory. Their actions range from classic belt-tightening to innovating and improving value-added services in their organizations. A primary value-adding strategy for the most effective organizations is to further improve project management.
In view of this strategy, the project management software industry's future looks especially promising. During the global recession, industrial countries around the world devoted billions in economic stimulus funds for infrastructure and other projects. This has created considerable demand for project management software.
In fact, the market for project management software and services totals about $1.2 billion annually, according to Forrester Research. The market for project portfolio management (PPM) software stood at $2.9 billion in 2008, according to IDC, which expects the PPM software and services market to reach $4.2 billion by 2013.
Companies and government agencies that are serious about project management have recognized for years that they can't manage larger projects and programs effectively without appropriate software support.
Indeed, project management software helps analyze, optimize and manage projects, and this lets organizations determine the right mix of projects and resources to accomplish their strategic goals. Without project management software, organizations find it difficult to track individual projects, the resources allocated to them and the costs associated with them. Similarly, without project portfolio management software, it is nearly impossible to manage portfolios of projects and the dependencies among them.
So what's the outlook for project management software over the next 10 to 15 years? For the answer, we must look at several trends that are helping to buoy the market for project management software and playing critical roles in its future.
Technology and Management Trends
On the technical side, software as a service, or SaaS, delivery models are making project management software more accessible to more organizations, particularly smaller ones. What's more, the growth of Web-based social media--from Facebook to Twitter--has put a focus on making project management software more collaborative, flexible and user-friendly. Today's project management software accelerates communication--across the hall or across great distances--and improves business results.
Another development that benefits project management software is the open-source movement. In the project management software market, this includes open-source versions of Project Workbench, one of the most popular project management software tools from the 1980s, and work-alike clones of today's most popular project management software (OpenProj).
The open-source movement provides an alternative that markedly reduces the total cost of ownership for project management software. It also gives commercial software an incentive to keep innovating and to improve its value proposition to customers. Longer term, the open source movement grows the market significantly because those who use the free versions eventually outgrow them and trade up to commercial tools.
On the management side, organizations are slowly but surely turning to a project-oriented approach to trim costs and add value. Due to cost containment and regulatory pressures, the cycle of centralized management systems is expected to come into vogue again. This will spark stronger project management offices (PMOs), which in turn may reduce the number of projects as organizations recognize the problems associated with running too many projects concurrently (especially if they don't have enough team members for each project). PMOs will look to project and portfolio management software to help them make these decisions.
The Potential
From our experience, every organization has the potential to improve its project management performance by an order of magnitude--or 10 times for each five to 10 year period, provided it commits to that goal. Given this potential benefit, along with economic and technological trends, demand for project management and project portfolio management software will almost certainly rise in the next 10 to 15 years.
This article builds upon information presented in the author's chapter in a new book, Project Management Circa 2025, published October 2009 by Project Management Institute.
Stacy A. Goff is president of ProjectExperts, a project management consulting, tools and training company. A PM practitioner since 1970 and PM consultant since 1982, he focuses on improving project management performance in industry, government and consulting firms.

Monday, March 15, 2010

The Case for Project Management - C. Wayne Peal



As all of those who have worked in the trenches well know, successful project management is the tie that binds services to results." So saidGovernment Executive in introducing a series of articles on successful federal projects in the July issue. But is the statement true? Do all in the trenches really know about project management? Do their leaders support and understand sound project management approaches? Are those approaches part of the culture of federal organizations? Is project management used appropriately - especially in guiding information technology projects?
I believe that the answer to all of these questions is no. Project management principles are used extensively in some federal organizations, notably NASA and the Defense Department. But project management is far less common in other federal agencies. Furthermore, shortcomings exist across the board when it comes to using modern project management approaches in information technology. What's more, the enormity of many federal projects would challenge even the most experienced project managers.
Just last April, Government Executive featured a special report, "Taming the Technology Beast," which drew some important lessons about project management from five large federal IT projects - successes and failures. It found, for example, that skilled proj- ect managers were in short supply in the federal government and that the massive scale of many federal projects was itself a major factor in failure.A survey conducted by Gopal Kapur, president of the Center for Project Management, at the December 1998 Government Technology Leadership Institute suggests that project management in the federal sector still has a long way to go - at least in the information technology world. Institute participants were polled on key aspects of project management in their organizations - including project selection criteria, schedule estimation, project manager skill levels, progress monitoring, portfolio management, and shutdown criteria. For each of the key questions, two-thirds to three-quarters of the federal IT managers attending said there were shortcomings.
The seven project management stories featured in the July issue ofGovernment Executive were selected from 70 presented in Alexander Laufer and Edward J. Hoffman's excellent new book, Project Management Success Stories: Lessons of Project Leaders (John Wiley & Sons, 2000). Based on the stories, Laufer and Hoffman identify a number of behaviors that they believe lead to success. They conclude that successful proj- ects are vitally dependent on good leadership balanced with effective management.
No single approach will guarantee complete project success. But Laufer and Hoffman have got it right - the appropriate balance of leadership and management processes can minimize the risk of schedule delays, cost increases, and failure of the final product to meet mission needs. Heroic leadership in a bad process may save a proj- ect, but it can take a heavy human toll. A rigid management process with no leadership will lead to stagnation. But it's becoming clearer every day that no project management at all is a recipe for disaster.
Take note of what the private sector is saying about project management. Five years ago, Fortune magazine quoted senior business sources who said that "project management is going to be huge in the next decade," and that it is "the wave of the future." Their prediction was correct. Proj- ects, large and small, are the key method in modern organizations for transforming ideas into products and services. Project teams are a vital component of today's more agile and responsive organizations, where change is the rule and cross-functional activities have become the norm. According to "The Y2K Dividend," a February article in Computerworld magazine, project management was a key element in successfully surmounting the challenge of Year 2000 technology transformation.
A project is a one-shot activity that has specified objectives and deliverables as well as time, cost, and quality targets. It is distinct from the other day-to-day activities that a federal agency or department must perform.
A sound project management approach can help you sort good ideas from bad, understand the complexity and risk of the undertaking, craft an overall approach, and provide initial estimates of cost and schedule. Project management methods will help you seek and understand the views of all those likely to be affected and identify likely obstacles. The project management approach also will provide an up-front outline of the conditions under which a project should be terminated. Knowing when to pull the plug at the outset can prevent the kind of runaway projects that have plagued both the public and private sectors.
Project management provides a broad framework, specific approaches, and tools to effectively plan and manage your approved projects. It can play a pivotal role in identifying human resource needs, getting the right person assigned to the right spot on the team and building effective communications. It provides a framework for gathering information, monitoring key indicators, and taking action to keep the work on track. And it documents key information for later use by the team and by teams that follow.
If project management is not being applied in your organization, you must become its champion. You must work toward its introduction, dealing with the resistance you may encounter along the way. I recom- mend that you start by holding a project management meeting with your own leadership team. Bring in someone who can speak from experience about the value of a sound project management approach.
Where can you learn more? Practitioners in other government agencies and departments and in the business world are more than willing to share their project management experiences. An armada of private consulting organizations awaits your call to action. A wealth of information is also available through professional organizations, such as the Project Management Institute (www.pmi.org).
Counter the Critics
Some disbelievers argue that project management entails too many rules and processes and that it can slow things down and stifle innovation. Their criticism is misdirected. The project management process need not be burdensome. By focusing attention on potential problems early and providing a well-understood process, it can actually ease pressures and facilitate innovation.
You may encounter "hard drivers" who prefer to proceed directly from an idea to the building of the product or service - skipping the initial scrub of the project idea and planning. Skipping those steps is a sure-fire formula for delays, cost growth and failure. Take, for example, the step of identifying project risks. Once risks are identified, you can work toward preventing or mitigating them. You won't identify everything that will go wrong, but you will ultimately save time and reserve your energies for the few risks you didn't anticipate.
Some critics argue that project management is inappropriate for IT projects. Heed their warnings. Although much of the traditional methodology applies to IT projects, significant differences exist between building systems and software and constructing bridges and buildings. If your concern is IT, make sure you find the right approach.
Finally, you will encounter those who argue that project management simply does not apply to the huge, complicated projects so often found in the federal government. The reverse is actually true. A large-scale, complex activity demands a systematic approach. The secret of project management is to divide the project into manageable pieces and knit them together using a larger blueprint or architecture.
When you've succeeded in developing a project management culture in your organization, is your work complete? Definitely not. Continuing support from the top is vital to project success. All project sponsors must understand their roles and actively commit time to their projects. Sponsors manage the project scope, ensuring that it remains focused on key mission needs. Vague direction and little involvement by a sponsor are a sure-fire formula for project failure.
How do these pieces come together for successful projects? Shaquille O'Neal may have the answer. In a recent television interview, the star offered a quote he attributed to Aristotle: "Excellence is not a single act, but a habit you do repeatedly."

Tuesday, February 16, 2010

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!

Friday, February 12, 2010

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

Tuesday, February 2, 2010

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.

Monday, February 1, 2010

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.

Thursday, January 28, 2010

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.

Monday, January 25, 2010

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.

Tuesday, January 19, 2010

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!

Monday, January 18, 2010

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. 

Friday, January 15, 2010

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.