Journyx Project Management Blog

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! (See my online article What’s Project Portfolio Management (PPM) and Why Should Project Managers Care About It?)

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.

Read more at: Michael Greer

In my years at Case/CNH, I was involved in three major system integration projects. These projects were similar in timeframe (one to two years) and cost ($5 to $10 million), but the results were much different. Inspired by the classic movie with Clint Eastwood, I call these three projects the “good, bad and ugly” of project management. The following is a brief review of these three projects and the valuable lessons that we learned.

The first project was necessary as a result of Case Company purchasing the agricultural division of International Harvester(IH) in the early 1980s.The goal of the project was to load all the IH data into the Case parts system and operate with a common parts system for both Case and IH. There was little advanced planning and no additional resources were assigned to complete the project. There was no project manager assigned and little management oversight and review. Since Case personnel initiated the project, there was little understanding of the features and requirements of the IH system and customers. The data load program and new programs were being written hours before the systems were merged without testing. The merged system had crashes, wrong data, and errors. Not surprisingly, for months following the merger customers, managers and employees were dissatisfied with the results of this project. It was ugly.

The second project involved adding a new forecasting and distribution requirement planning (DRP) system to the existing parts system. A team was formed that identified the required features and did a make/ buy analysis for the new system. After review the team decided to buy the software from ASI and build interfaces with the existing system. A project manager was established and a project team attended several training programs to learn how the ASI module operated. The new system and integration to the existing system was tested and debugged thoroughly in advance. The system implementation went smoothly, but the system didn’t contain the features the users needed. It was discovered that several of the required features didn’t work as expected. Forecasts could be only adjusted monthly, monthly forecast buckets were used where weekly buckets were expected, and the system parameters were difficult to adjust. After five years of struggling with the new system it was deactivated and a new system was established. This project failed, because the planning and software investigation at the front end was faulty. I classify the ASI project as bad.

The third project was to establish one global part systems to replace numerous stand-alone systems in various countries. A dedicated project team was established and they identified key features such as: different languages and currency, country/region designations and country of origin codes. The project was planned and the scope approved by management in regard to cost, time, and quality (features) of the new global system. A global project team was established with leaders identified for each country and functional area. There were frequent project updates and project plans were changed as needed. Before implementation users tested each segment of the new project. Testing provided the chance to learn the new system and doubled as user training. Documentation and training manuals were completed. After implementation a “war room” was established to identify and fix unexpected problems. This was a project that I’d classify as “good”.

Lessons learned - I learned several lessons from these good, bad and ugly projects…

Read more at: PROJECTmagazine

A young programmer approached Mary Finlay with a request: After just a year on the job, he wanted to work four 10-hour days so he could have every Friday off, a schedule that would allow him to play Thursday night gigs with his rock band without worrying about the next day’s work.

Many IT executives would say no, but Finlay, deputy CIO at Partners HealthCare System Inc. in Boston, OK’d the plan. “He was smart and talented, and we wanted to keep him,” she explains.

Her decision paid off: He stayed with Partners for nearly a decade.

…

“Study after study shows that it is extremely cost-effective and very good business to provide flexibility to your employees,” says Barbara Wankoff, national director of workplace solutions at KPMG LLP, an audit, tax and business advisory firm in New York. “Employee morale, employee productivity, retention, historical knowledge — all of those things improve when people feel they have more control over when, where and how they work.”

Read more at: Computerworld

The compiler removes them completely. The computer ignores them. Some developers think we should do away with them entirely. But in the grand scheme of software development, I personally think they have a very important part to play. What are they? Comments, of course. Now, that’s not to say that all comments are created equal, or that you should just sprinkle your code with comments without thinking about what you’re doing. But in my experience, good developers recognize that comments are a useful tool, and employ them to make code more clear and maintainable. With some practice, you can do the same.

Read more at: Developer.com

A “To Do” List and Items to Help You Execute, Control, and Close Out Your Project

(This is a sample tool from The Project Manager’s Partner, by Michael Greer.)

Instructions: After your project plan is approved and you are up and running, you can use the checklist below and related items to help you keep things moving according to your plan. Go through this list at least weekly for each project you are managing.

CHECK YOUR PROJECT’S SCOPE.

Refresh your memory about your project’s goals and boundaries. In particular, make sure you have a clear picture of what the desired results should be at this point relative to deliverables, schedule costs, quality, and so on.

(See Worksheet: Project Scope Statement* under Action Item: Describe Project Scope if you don’t already have a formal scope statement.*)

CHECK YOUR DELIVERABLES.

Analyze the status of each project deliverable. Are they evolving as planned? If appropriate:

1. Locate lists of quality criteria that may be applied to inspect the quality and completeness of the deliverables at this stage of the project.

2. Check contractors’ proposals or contracts to make sure you know what they should be supplying at this point.

3. Inspect all project deliverables.

4. Decide whether to accept inspected deliverables or to require rework.

(See Worksheet: Project Deliverables Status Analyzer.*)

Read more at: Michael Greer

• How can I manage long project and task lists for performance and ease of use on timesheets?
• Update - In Timesheet, what is the procedure for handling an employee who is leaving my company?

Get these great tips and more at:
http://journyx.com/rss/support/tips/

Project assurance expert Pelicam warns of the pitfalls of poor measurement in IT projects and calls for higher industry standards. The company outlines nine key points for effective IT measurement.

It’s one of the oldest adages in management: ‘What gets measured gets done’. Yet examples of the unintended consequences of measurement systems continue to abound, and IT is one of the worst culprits.

For example, a common key measurement is IT spend in comparison to income. How is this to be interpreted? A high ratio might equally indicate a company investing in systems to support future growth - or poor cost control.

What ought to be measured, in addition to IT expenditure, is the value IT delivers to the organisation - that is, the output as well as the input. Good CIOs understand this, but not everybody in IT behaves in a way that recognises it. Some take pride in having ‘the latest’ of everything in their infrastructure, regardless of whether the business actually needs it (and so do some of their end users - witness the competition to see who has got the latest Blackberry model).

Another example of poor measurement in IT is the Service Level Agreement. Too often SLAs are based on what’s easy to measure, such as percentage availability time on a network, rather than what’s important to the user - such as how often, in critical periods, was the application unavailable; or what was the cost to the business of unavailability?

Peek behind the curtain at:
http://journyx.com/rss/redir/projmag-measure.html

Ah, the holiday season. Regardless of which holiday you’re celebrating this time of year, you can count on Aunt Irma or Grampa Morris or someone hauling out the old family stories. You know, the ones that get told at every family gathering, every year, year after year, forever? Oh yes, you know them. We do, too. Heck, at Journyx we even have one of our own. It dates all the way back to the early years of the 21st Century. It’s called “Journyx And Santa” and we link to it every year just so you can appreciate your own family all the more…

Hermey changed the report to Cube Report format and clicked the Export to Excel button. Once Excel opened with the data, Hermey quickly added a calculated percentage column. Hermey pointed to the Furby percentage. Even the old man had to be stunned at this.

Read on and relieve the good ol’ days one more time at:
http://www.journyx.com/rss/santa.html

We’ve all heard plenty of project team analogies. For me, the most fascinating one compares a project to a football game. Each has an objective, a team that needs to be coordinated and a deadline.

I’ve devised a little tool that extends the analogy further. Football coaches have long made use of playbooks to ensure accurate communication, visual sequencing and coordination among team members spread over a large area. I’ve found that a playbook can serve the same purpose for a virtual team working on a small project.

My playbook is based on the classic issue log. Instead of being an incongruent list of problems, however, it’s a sequential list of tasks. It clearly shows everyone the order of the work, who is being called on and when.

By their nature, virtual teams work as a collection of free agents, and conference calls among team members have a tendency to become disembodied forums of multiple conversations, divided attention spans and mayhem. Given that most of my virtual teams are located across the country or around the world, I need a more focused means of getting results. The playbook is that mechanism.

Learn the plays at:
http://journyx.com/rss/redir/cworld-small.html

You probably already know that Journyx is based in Austin, Texas, which is home to the world-class University of Texas. A good number of our staff even attended said university. Most of the rest of them wish they did. In any case, this proximity to such a well-regarded institution of higher learning has bred a certain belief in the power of learning into our institutional bones. We believe in education because we believe that knowledge is power.

That’s why we’re pleased to announce the Journyx “Excellence In Project Accounting Philosophy” Essay Scholarship (Graduate Level) for 2007. With this scholarship, Journyx will be awarding $500 USD to a Masters or PhD candidate to be applied to tuition and fees at an accredited university in the United States (sorry international customers - we’re working on a scholarship opportunity for y’all, too). All we ask in return is the best darn 1,000 word essay on project accounting you can write.

We’ll be accepting entries starting January 1, 2007 and will shut down the process for judging on June 1, 2007. You can get the complete details, rules, regulations, legalese and application procedures on the Journyx website - http://scholarship.journyx.com - where we’ll also post information on future scholarships sponsored by Journyx when they’re ready for you. Meanwhile, if you or someone you know is a graduate student who could use an extra $500 USD, get writing!

Get all the details and full rules at:
http://journyx.com/rss/company/scholarship.html