My Project Is Not Failing

March 27th, 2013

Maybe we are all reluctant to accept that our project might be failing but with high project failure rates in many industry sectors we should make sure we are able to spot the main warning signs. And then act on them rather bury our heads in the sand and hope it will “be alright on the night”. That approach will never lead to a successful project or a successful career in project management.

Just because things might not be going to plan doesn’t mean a project is doomed – managing problems and risks is all part and parcel of a project manager’s role and a risk management plan should be in place that will help to mitigate the very risks that might be causing problems. If a risk plan has not been prepared, don’t worry it is rarely too late to review the real and potential risks that might be threatening your project and to deal with them effectively. Problems that materialise in a project, whether expected or not, are inevitable in many industries and with a controlled approach they can usually be mitigated.

The very fact that problems so often arise in IT projects, for instance, is what led, at the beginning of this century, to the creation of the Agile Manifesto, with its values and principles designed to help project managers work constructively to solve problems rather than either being defeated by them or trying to ignore them. An agile approach recognises that many projects are simply unsuited to the traditional “waterfall” approach and offers an alternative where deliveries are made in small stages allowing for user feedback to be incorporated into the next stage. Increasingly both waterfall and agile methods are recognised as appropriate for different types of projects and in some cases they are being combined on a single project.  All projects have their ups and downs so it is important to remain optimistic in the low periods and remember that things will change.

It is reassuring that the formalisation of project management methodologies over the past 20 years has led to a significant improvement in project success rates. Increased used of the internet has also helped by making status reports quickly and easily available so that problems don’t drag on undetected for too long.

 So what are the warning signs of a project that could be destined for failure? If your know how to spot these and act on them you already have the means to turn a potential disaster into a success. Warning signs of pending trouble are usually relatively easy to spot – here are some typical ones:

 1.      Lack of Buy-In

When those working on a project have been pressured into becoming involved they will never be fully committed to its success and will not give 100% of their time or energy to the project.

2.      Poor Communication

Communication takes many forms; there are the informal team discussions, regular meetings, emails, phone calls and various written reports and other documentation. If any of these areas are lacking then there is likely to be a problem looming.

3.      No Visible Progress

If it is not possible to see what has been achieved to date then it is difficult to convince stakeholders and the team that success is possible. A lack of visible progress (or “velocity” in Agile project management) is de-moralising for everyone involved.

4.      Long Hours

If the project team are having to put in long hours just to stay on top of the scheduled activities then this is a classic indicator that all is not well. Either the original estimates were badly wrong or the scale and scope of the work was not clear.

5.      Milestones Missed

Milestones should deliver manageable chunks of work to the customer on a frequent basis. If this is not being done, or the deliverables cannot be tested by the customer, there is no opportunity to get feedback for the next phase to know the project is on the right track.

6.      Changing Scope

Every project’s nightmare is scope creep – adding to the requirements during the project – it is usually an indication that requirements were not fully documented or the customer did not understand the aim of the project. But often a more serious warning sign is when features are being removed from scope and the end-product is being scaled back.

Remember that warning signs such as these give you the opportunity to rescue a project from failure so should not be ignored but treated as part of the project management process. By looking out for warning signs and using your experience and personal skills (supplemented with the right project management courses) a project manager can avoid project failure.

Author: Michelle Symonds

Free directory of online courses

March 7th, 2013

The project — http://www.onlinecourses.com/ — is a free and comprehensive resource that is a collection of open college course that spans videos, audio lectures, and notes given by professors at Harvard, Princeton and MIT. We offer highly relevant courses such as iPhone Application Development from Stanford and Cyber Humor from Oxford. This is something I believe would be a wonderful resource for those looking to explore additional educational topics and to see what college level course has to offer.

I hope that you will find this to be a powerful resource for anyone pursuing to further their education. Please take a look and let me know what you think.

ProjectLibre – Free project management software

October 9th, 2012

This is another of our free alternatives to Microsoft Project.  From the reviews it is a relatively similar product to Microsoft Project.  It has a ribbon menu and covers such things as scheduling and resources.  It can provide Gantt, Network and work breakdown structure.  The only thing missing seems to be a body of knowledge or help files.

For more information Click Here

Free Project Management Software

September 13th, 2012

Over the coming months, we plan to list some free software to manage your projects. The first is called GanttProject. It is an open source solution that runs on most platforms. We reproduce the following summary from their website.

GanttProject is a cross-platform desktop tool for project scheduling and management. It runs on Windows, Linux and MacOSX, it is free and its code is opensource. What can it do?

Gantt chart. Create work breakdown structure, draw dependencies, define milestones.
Resources. Assign human resources to work on tasks, see their allocation on the Resource Load chart.
PERT chart. Generate PERT chart from Gantt chart.
Export. Save charts as PNG images, generate PDF and HTML reports.
Interoperate. Import projects from and export them to Microsoft Project formats. Export to spreadsheets with CSV.
Collaborate. Share projects with your colleagues using WebDAV.

For more information you can go to http://www.ganttproject.biz/

Rescuing a failing project – A 4 step plan

June 28th, 2012

Projects can fail for numerous reasons. Original budgets may not match the practical realities of a project, or the responsibilities and roles of team members may not have been clearly outlined at the beginning of the planning process.

A general lack of clarity about the direction of a project, and a failure of communication between different stakeholders and parties can also delay success and lead to confusion about responsibility over project delivery.

However, there are ways to rescue a failing project, which involve engaging with a four step plan that reviews, revises and resets goals and communication for a project, while working out the best forms for its delivery.

 

1 – Reviewing Problems

The first step in rescuing a project is to review the problems that caused it to fail, or be delayed. Re-evaluate the original goals of a project, and break down what the plan was, and whether overestimations were made.

Moreover, check that anything was not picked up on in the planning stage, and bring in as many different viewpoints as possible. These viewpoints might include managers, team members, sponsors and stakeholders. At this stage, it is also worth making a hard decision about whether a project can be saved.

2 – Revise and Set Out New Goals

If a project goes ahead, draw up new goals and a set of differentials that will ensure a better delivery. Are there extra factors that need to be budgeted for? What are the expectations and the input of stakeholders and sponsors? Can a system be put into place that can deal with risk, and that can swiftly respond to any problems?

Getting this structure right before setting a deadline is vital, as it ensures that no one in a project team feels like they don’t understand how to react to any obstacles during their work.

3 – Ensure New Expectations Are Met

Ensuring that these new expectations are met does mean being pragmatic about budgeting and the restructuring of a team. What needs to be reduced, and how can communication be managed to speed up the process of a project to best meet deadlines and priorities?

Moreover, it is important to decide what the focus of particular parts of a project will now be, and how much of a budget can be realistically spread out to hit the parts of a project that need the most attention.

4 – Decide When the New Project Will Be Delivered

A clear deadline needs to be made for when a project will be delivered, which will need to be agreed on amongst a team and other parties. Again, communication is vital to ensure that everyone stays on the same page.

A software project management tool is particularly recommended for achieving this communication, as it can enable realtime conversations and an exchange of information.

Similarly, by restructuring a management team and ensuring that there are contacts that people can rely on to troubleshoot any problems, it is possible to refocus a project into something that has shared aims and failsafes.

While rescuing a failing project does require a lot of hard work, by creating a strong team environment, and by establishing a clearly structured management structure, the original goals of a project can be revived and clarified for all involved.

Amy Henderson

Amy Henderson has been involved in running a business in the past. Amy enjoys writing on business/technology related topics and is currently guest blogging on behalf of Iris who specialise in small business software.

Project Perfect Members Club

June 16th, 2012

For those of you who regularly visit our site, you will not have seen much activity over the last few weeks. We have been busy building a whole new area for you. Welcome to the <b style=”color:black;background-color:#ffff66″>Project Perfect Members Club.</b> As well as our library of over 150 white papers, we offer lots of other goodies.

  • Free software.  Get our Meeting Administrator and Method H software for free.  Method H normally sells for A$35.
  • Project Management Templates.  A whole range of templates to help you with your project management.
  • User Guides.  Documents that guide you through regular tasks such as risk management, carrying out interviews, managing scope, and lots more.
  • 40% discount on a single user license for Project Administrator when you pay an annual subscription to the members club.  The discount pays for your annual subscription.
  • Access to Software Package Selection Process.  SP2 is our online methodology for undertaking a software selection and implementation. Most of the methodology is applicable to any project.

There is lots more to come.  We plan to expand the offerings to make our members club a vital part of any project managers toolbox.

You can subscribe for A$10 per month and cancel at any time.  If you want to save some money, pay an annual subscription of A$100.  At the time of writing this post – mid June 2012 – the A$ is on parity with the US$. A$1 = US$1.

Click here to register.

Click here to find out more.

Using Project Management for Web Development

May 30th, 2012

Even the most talented web developers might not be adept at planning and managing a project from start to finish. In fact, many web developers find themselves struggling to complete their work on time and under budget. Implementing project management techniques can help developers create an organized plan that leads to successful projects.

Create a thorough contract

Your first priority on any project should be to establish a fair and detailed contract that protects both you and your client. Be as specific as possible in outlining milestones, deadlines, payments, and cancellations so there is absolutely no confusion or miscommunication once the project is underway.

There are numerous contract templates available on the web which you may use as a reference, but to ensure the security of your business and livelihood, it is highly recommended that you seek the professional services of an attorney.

Create a specific plan that covers all areas of the project

Once your contract is in place, having a road map is imperative to the success of any development project. It should target all of the different phases such as research, design, coding and testing, and establish a cohesive plan of action so your client is aware of the exact process. Each phases’ goals should be clearly defined and completion dates highlighted. Make sure to have your client sign off on this and include a copy with your contract.

Next, be sure to establish a style guide for the project and decide early on how the site will ultimately look and feel. Use mood boards to communicate effectively with your client, and refer to these boards as often as necessary to ensure your work is consistent and aligned with the project’s goals. People have a tendency to change their minds about how the site should look as the project moves along, so once a style has been agreed upon, be sure to have your client sign off on it.

Finally, before beginning the actual work, make sure to take the time you need to research, plan and test. It’s common for developers to be enthusiastic about a project and want to dive right in, but without this initial preparation, you’re asking for trouble down the road.

Set deadlines that are realistic

You’ve landed a big client and are ready to deliver a project that will knock their digital socks off. Just make sure you’re realistic about how long the project will actually take. Set milestones and deadlines that reflect the progress plan you’ve thoroughly outlined. As you create these milestones, be sensible. Setting unrealistic goals can cause you to rush the project, which can result in mistakes or less-than-optimal production.

Your ultimate goal is a satisfied client that will come back for more, so don’t rush to reach unrealistic deadlines.

Use project management software

Managing your development project is a highly challenging endeavor because of the numerous tasks and sub-tasks that must be implemented. It’s easy to become distracted and lose sight of the big picture. This is why it’s a good idea to utilize project management software that will help you keep track of scope, deadlines and budget, and allow for effective communication with your client throughout the entire process. Without the kind of organization this management software provides, a project could easily and quickly derail.

Document everything

Documentation is the key to delivering a successful project now, as well as those you develop in the future. Take notes whenever you meet with your client, whether in person or electronically, to make sure you hear and record every detail of their wants and needs. Often something will be said in a conversation that, if missed or forgotten, can mean major changes in code or functionality. Save yourself a headache and make sure you document everything.

As a programmer, you’re aware that programming styles and your own skills will evolve over time, and this will make it difficult in the future to go back and tweak old code. By documenting your code as you go, making sure to use descriptive names and explain a feature’s purpose and function, you are reminding your “future self” how and why you did something. While writing notes for yourself, it’s also a good idea to draft end user documentation that will make it easy to train your client on the software.

Project management techniques streamline and organize what can be a very muddied and distracting process. As a web developer, using these techniques in your own work can help ensure you deliver amazing websites to your clients each and every time.

Erin Palmer works for University Alliance and writes about their project management certification programs. To learn more about PMP requirements please visit http://www.villanovau.com.

Lessons on the Wrong Resource

April 3rd, 2012

Here is a lesson I learned when doing a project review.  I guess I knew it all along but it was certainly brought home to me when I did the review.

A large public corporation had just finished a project.  It had been difficult to say the least.  It was well over budget and time.  The deliverables were not in line with the original scope statement and there was already talk of a “Stage Two”.  The project had been particularly political and I was brought in as an independent person to review the project and identify any lessons learned.

In preliminary discussions it was hinted strongly that the problem was the project manager.  He had not taken control of the project, and many things had not been done properly.  He set adventurous deadlines and did not manage the business staff well.  I kept an open mind but there was certainly a perception that the project manager was to blame.

I reviewed the project documentation before starting interviews and it did appear weak.  The risk assessment was only done once, and appeared superficial.  There was little follow up on mitigation strategies.  There was no documented process for managing variations.  The schedule updates seemed to be sporadic.  There was no Project Plan.  Some of the content you would expect to find in a project plan was scattered through a number of other documents and some just missing.  It was evident from the documentation project management was weak.

I interviewed the project manager and he was very defensive.  He pointed the finger at many people who had contributed to the problems.  He claimed lack of support, and lack of authority.  Decisions were taken without his knowledge and he was later informed.  One example was a major variation that was agreed without him being aware of the proposal.  He was told to just go do it.  Clearly he was not in control.

As we proceeded, I asked about his previous experience.  I was astonished to find that he had never undertaken a project this big.  In fact his biggest project would barely be a tenth the size of this project.  I asked him how it was that he came to run the project.  His answer was that it had been presented to him as a chance to prove his worth.  An opportunity to show people what he could do.  The break he had been looking for to advance his career.  He had no formal training.  He had carried out a few small projects but never been trained in project management.

Once I knew this, I could understand his perspective.  He found:

  • People were not cooperating as he expected them to
  • Verbal assurances were never honoured
  • Decisions of a critical nature were not being made with his input
  • The staff he was given were not up to the job requirements
  • The original estimates he was given were not realistic

The worse it got, the more he found people finding a way around him to run their own agenda.  He was not only out of his depth.  He was set up to fail.

So where did the blame lie?  Most people, including myself, have taken on a task and found it was much more complex than we imagined.  In some cases we have taken it on because we pushed to be there, and in other cases we were pushed into the situation.  In the former case , we may be able to lay some blame at the feet of the person who gave in to our demands to allow us to carry out the task but mostly, we have ourselves to blame.  In the latter case, the main person to blame is the person who pushed us into the situation then set us adrift.  The project manager was definitely the latter case.  He was pushed into the role, his reservations were smoothed over, and then he was set adrift.

My report identified this as the problem, and the person who was Sponsor was the person responsible.  What I couldn’t say in the report, much less prove, was that the poor guy was appointed because the Sponsor wanted someone he could dominate and who would not stand up to him over project issues.  I recommended the project manager be given proper training and continue working in that role but on smaller projects until he built up his experience.

A year later I had coffee with a person from the corporation and asked what had happened.  Unfortunately there was no fairy tale ending.  The project manager had resigned, or been forced to resign.  It was not clear.  The Sponsor had rubbished my report and said I would never work for them again.  Stage two of the project had been outsourced and was now causing bitter disputes within the organisation.

I did work for them again.  After about three years, the Sponsor had moved on, and I was approached to do some more work for the corporation.  Evidently someone had said to the CEO that they needed someone who would “tell it as it is” and I had proved I would three years previously.

The lesson to come from all this is that you need the right resources.  In this case it was the project manager but I have seen the same situation in every project role.  Not putting in place the right person will come back to bite the project somewhere down the track.  The other lesson is to make sure that you have the capability to do the job when it is offered to you.  There is an old saying “beware of Greeks bearing gifts”.  I think it refers to Trojan horses, but in the world of the GFC, it is just as appropriate today.

Microsoft Access referring to controls on subforms

March 23rd, 2012

I recently replied to a question on a newsgroup and thought it was worth reproducing here.  The question was how do you refer to a text box on a form within a form within a form.  In other words, the main form has a subform and the subform has a subform.  To refer to a control that is on a sub sub form, you need to understand the following.

In the example there are three forms. frmMainForm, frmSubForm, frmSubSubForm

On frmMainForm is a subform control called subSubform Within that control the source object is frmSubForm. The thing to remember is that you refer to the control not the subForm within the control. You refer to Forms![frmMainForm]!subSubForm] not to Forms![frmMainForm]![frmSubform].

Think of it this way. If you only had one form, and you wanted to refer to the value in a textbox, you would refer to the textbox name, not the textbox data. If you had a textbox control called txtCustomer containing a table field name which might be tblCustomers.CustomerName, you would refer to the value as Me!txtCustomer rather than Me!CustomerName. Same with subForms. Refer to the control name, not the value (form name) within the control.

You have now referred to the control on the main form. The next step is to say what part of that control do you want to refer to? You want to refer to the Form part (Form object). You now add .Form to the path. Notice it is a dot rather than exclamation mark because it is not a field but a property. It could have been a property such as .Height or .Visible if you were referring to properties. If it was a control on the subform,you would have used “!” instead of “.”

Now you have made it to the subform, you want to get to the subsubform. Once again refer to the control on the subform which we will call subSubSubForm. We want to look at a control on the subsubform so we use .Form again and then the name of the control.

The full path is below.

Forms![frmMainForm]![subSubform].Form![subSubSubForm].Form![txtOnSubSubForm]

Forms - Collection of forms in the database
![frmMainForm] - We are referring to a user created object so prefix with an exclamation mark. The form we are interested in is frmMainForm
![subSubform] - Refer to a control on frmMainForm which holds a subform called frmSubForm. We don’t need to mention the subForm name, only the control name
.Form - The form that sits within the control is now the focus
![subSubSubForm] - Find a control on the subform that contains the second subform
.Form - The value we are interested in the subsubform is the form object itself
![txtOnSubSubForm] - Finally we reach the control on the subsubform that we want to use.

Hope all this makes some sense. Just remember you only ever refer to the main form by name. The rest of the form names are irrelevant. It is the control names that matter.

White Paper on Global Project Management

March 14th, 2012

In a world where cloud and mobile technologies have eliminated the barriers of communication and collaboration across borders, oceans and time zones, project-centric organizations are increasingly mining the world for the best talent to deliver quality goods and services. In turn, this new global economy has created a more competitive environment where businesses are required to deliver superior products and services to more demanding customers at lower margins. In light of this reality, project-driven organizations must continuously improve their global strategy to maintain their competitive edge and remain profitable.

This white paper will examine the unique challenges confronted by project leaders and their dispersed teams and stakeholders, and the strategy required to effectively drive projects to success. Click here to read more