I'm hearing the phrase User Experience thrown around quite a bit these days. It's become an overloaded term that means different things to different folks, yet we all seem to agree with the premise that a positive user experience is essential.

Platinum Solutions Delivery Methodology (PSDM) defines the standard processes, templates, and guidelines utilized on Platinum Solutions software development projects. This methodology is based upon years of successful project delivery and industry best practices, and promotes efficient, reliable, and predictable projects. PSDM provides project team members easy access to processes, templates, and samples which can be tailored to fit individual project needs.

Did you know that the Hudson project has grown from 200,000 to 500,000 lines of code since January of 2007?

Did you know there's a guy in France (Jim Meyering) who has contributed to the GCC, CVS, Emacs, and Perl projects?

The website ohloh.com has this and lots of other interesting information about open source projects.

I am sure you have been in a situation where you need to open a MS Project file but do not have MS Project. Now, you have easy solulion. It is called "OpenProj", an open source, freeware software by Projity is a desktop replacement of Microsoft Project. OpenProj has equivalent functionality, a familiar user interface and even opens existing MSProject files. OpenProj is interoperable with Project, with a Gantt Chart and PERT chart etc. Check it out at: http://sourceforge.net/projects/openproj/

I've recently finished reading Web Project Management: Delivering Successful Commercial Web Sites, by E-commerce guru Ashley Friedlein.

The idea of listening to your customer is one that should never be dismissed. But surprisingly, I often see it happening by other contractors. I refuse to buy the argument that customers aren’t equipped with the ability to know what they want. Some may need assistance with technical jargon, but a web application is not always just a web application.

Perhaps you’ve worked with this guy I know. He holds the record for World’s Fastest Programmer. Nothing is new to him. He’s seen it all. In fact, he doesn’t even have time to discuss it. He has code to write! Well obviously, a great coder alone is not a competent software engineer.  Coding is just one of the many areas in which we must excel in order to complete the job. Truly useful systems must be well-designed. High-quality systems must be thoroughly tested. Easily maintainable systems must be well-documented.

While at the NFJS Software Symposium this weekend, I attended a talk given by David Hussman titled: Creating, Telling, and Tracking User Stories.  Not having any prior knowledge of this concept I was very intrigued by what he had to say.

Apparently, user stories are an XP method that facilitates and drives requirements gathering, release and iteration planning, and the creation of solid acceptance tests.  Basically, user stories are a compilation of a few sentences that are compiled by the actual users describing what they need the system to do in order for them to do their job effectively.  Having these user stories allows us to live a day in the life of that specific user.  This can open up some new doors when it comes to how we develop.  If we have a better idea of what the users actually need, then we will be ahead of the game.  Anyways, David made some very good points during his talk and I thought it was an interesting concept and worth looking into.

More cases than not, a project will have requirements that will not always be complete.  At times, clients seem to think that they can provide you with a set of requirements, come back in six to eight months, and get a quality system. Because of this, it is difficult to make your client understand that they are vital to the success of the project.  In my personal experience, the way to cross this bridge is through communication.  Here are some examples of practices you can put into effect on your project to increase client-contractor interaction:

Throughout my projects, every time I was required to make a decision, I asked myself the question, do I get input from the team first, or do I make the decision and then enforce it without prior team input.  Each approach has its benefits and over the years, I have found that getting input from team members builds cohesiveness amongst team members.  The Collaborative Approach makes team members feel they are part of the team, and are important to the team.  Once the decision is made in a collaborative environment, it is more likely that team members will implement/follow the decision.  The team stays focused on the goal at hand.  A big part of the success of my current project had to do with listening to the team’s input.

An Iterative Approach to Data Migration

Data Migration is the process of moving required (and most often very large) volumes of data from existing systems to new systems. I found that such projects can benefit from the use of a tailored development process. This process I came up with can be broken down into three phases.

      Requirements and Design Phase (Mostly requirements gathering activities)