Posts Tagged ‘Project Management’

Project Perfect Members Club

Saturday, 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

Wednesday, 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

Tuesday, 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.

White Paper on Global Project Management

Wednesday, 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

Lesson on Identifying the Outcome and the Problem.

Monday, March 12th, 2012

What is the problem the project is trying to solve?  Think about your current project.  Can you answer that question?  Why is it even important?

Every project is trying to solve a problem.  The problem may be:

  • We cannot cross a river
  • There is an opportunity to claim a niche market
  • Our software is no longer supported

If the problem is identified, the outcome can be identified.  It is not the solution.  There is a difference.  Taking the first example, the outcome is that we need to cross the river.  The solution may be a tunnel, a bridge or a ferry.  We might select a bridge as the solution, but it may not necessarily be the only or even best solution.  A business case needs to be developed to look at how we can achieve our outcome and nominate the most suitable solution.

Too many people focus on the solution rather than the outcome. In the second example we might say let’s build a new product to meet a niche market.  Perhaps the solution could be to have someone else build the product, or to patent the solution and sell the patent.

This particular lesson came from a review of a project in crisis.  A stockbroking firm were building a new client information and transaction system.  They had employed a company to build a web based solution.  There had been numerous prototypes built but they could not settle on the final product.  The CIO called me in to try and resolve the situation.  My assignment was to last a week.  I was gone in two days – very poor form for a consultant.  This is how it happened.

My first interview was with The Financial Manager.  They were providing the funding and were co-sponsors of the project.  I asked what outcome they were trying to achieve.  The response was that they were trying to provide better customer service and retain their client base.  In fact I think they were trying to keep up with their competitors rather than surpass them.  In order to do this for the minimum cost, as things were tight financially, the solution was to develop a simple interface that allowed customers to undertake basic transactions and see core information.

My next interview was with the other co-sponsor, the Marketing Director.  I started by asking the same question.  His outcome was a bit broader than the Financial Manager.  He also wanted to provide better customer service but also wanted to attract new customers from his competitors.  In order to do this, his solution was to build the best, most sophisticated customer interface in the industry.

In the afternoon I spoke to the company building the system.  It took a while to get to the truth but the crux of it was they built prototype A and showed it to the Marketing Director.  Add more bells and whistles said the Marketing Director.  They did and showed prototype B to the Financial Manager.  Take out the bells and whistles said the Financial Manager.  We can’t afford them.  Back and forward they went from one to the other adding and removing features.  It was a bit more subtle than how I explained it but the software developer was happy.  They were being paid by the day so variations were all paying work.

By the end of the first day I went back to the CEO and said this.

“The problem may be that you risk loosing existing customers.  In this case the outcome may be to improve services to existing customers.  The problem may also be that you need additional customers to build the business.  One solution may be to attract customers away from your competitors by offering more attractive services.  Both have a potentially different solution so until you decide the problem and outcome, you cannot set the path forward. “

Day two started with a meeting between the CEO, Financial Manager and Marketing Director.  The two co-sponsors explained their perceived problems and desired outcome independently.  There was considerable discussion on which problem was relevant, and it was decided that for this project, we only wanted to look at the problem relating to retaining existing customers.  We then matched where the outcomes were the same and highlighted where the outcomes were different.  Different included outcomes where only one of the co-sponsors had a desired outcome.  It took several hours of debate, and a few directions from the CEO before they had an agreed, common outcome.  That outcome did not include stealing customers from their competitors.  We then worked on the best solution, and by lunch time we had an agreed solution which formed the scope of the work required.  We invited the development team in, and matched their work to the scope statement.  By the end of the day, a conceptual prototype was agreed.  It was in fact a stripped down version of the most recent prototype.

Ready to go home at the end of the second day, I was drawn aside by the Marketing Director.  He asked “If we have another project, and the outcome is to attract our competitor’s customers, what would be the solution?”  I had to point out that there were many solutions.  He had to identify the solutions and evaluate which of those had the best business case.  It may be to enhance the basic customer information system or it may be a new product to attract those investors.  I think the lights finally came on.  He got it.

I did hear from him a few months later when he asked me to facilitate a meeting of his key managers.

“We want to talk about outcomes” he said.  “I want my team to brainstorm solutions and then we can go away and develop business cases for them.”

I asked him how the new customer information system was going.  It was in place, and getting good feedback from the existing clients.  He said he couldn’t understand how it had taken so long to get started.  Sometimes you think you have broken through and then the person confirms there is still some way to go.