Journyx Project Management Blog

The Project Performance Improvement Model

Would you develop 10-year-old hockey players the same as NHL players? Of course not. One needs to learn the basics while having fun. The other needs to establish a level of expertise in executing a more sophisticated game plan. In either case, the coach must use an approach that meets the unique needs of the individual. In the same way, project teams have individuals with varying degrees of knowledge and skill that calls for a flexible approach.

Taking our Lead from Sports

Examples of sports coaching success illustrate how coaches are able to transform a group of individuals into a team, motivated to execute a well-defined plan. To become highly motivated, each individual must understand the plan and their role, and how they will contribute to the team’s goals. Accepting the role they will play is a precursor to becoming motivated, and this requires a system that takes advantage of the individual’s strengths and provides an opportunity to work on their weaknesses. Collectively, over time, the team works toward becoming highly efficient at executing the plan. For example, the Edmonton Oilers Stanley Cup days involved a very potent offensive club that took advantage of skilled offensive players, such as Wayne Gretzky, Mark Messier, and Paul Coffey, supported by equally skilled defensive players. The team was successful because it was built on the strengths of all players.

How the plan is implemented has a profound influence on the team’s success. Coaches such as Scotty Bowman and Vince Lombardi were successful because their approach to coaching players was as important as the plan. Sending players away for development, or bringing highly qualified players onto the team, may lead to short-term results. However, championship teams are successful because
every player has a clearly defined role in the effective execution of the game plan, over both the short and long term…

Read more at: ProjectTimes

There’s a culture clash inside office buildings where workers from the busyness economy sit in cubicles next to workers from the burst economy — web workers. Yes, that’s right: even if you work as a corporate employee in an office building, you may still be a web worker, using the Web for radical and unconventional productivity. If you are, your coworkers who don’t get how the Web changes work may think you’re a malingerer, given your incessant online connecting and surfing combined with your lack of attention to the old rules of work.

The busyness economy works on face time, incremental improvement, strategic long-term planning, return on investment, and hierarchical control. The burst economy, enabled by the Web, works on innovation, flat knowledge networks, and discontinuous productivity…

Read more at: Web Worker Daily

To paraphrase the old Wolf Brand Chili ads, “How long has it been since you last looked at the Journyx Case Study Archive? Well partner, that’s too long.”

We’ve added some new case studies to the list recently and one of them is just bound to be something you need to read. Because whether you’re currently using Timesheet or are still thinking about investing in Journyx, seeing how we’ve been able to help other customers can inspire you to look at your business in new ways.

So, without further ado, let us (re)introduce you to the Journyx Case Study Archive. Here you’ll find an ever-growing number of case studies that give you invaluable insight into the magic that Journyx can work for you.

Browse the case study archive at: http://journyx.com/rss/press/caseindex.html

We’ve waxed rhapsodically about him time and again, but this time Curt Finch, founder and CEO of our little Journyx, has outdone himself. We’re happy to announce that Curt is now a featured contributor to the Inc.com’s technology blog, Business Bytes. So if you’d like to take a trip inside the mind of the CEO of a multi-million dollar software company, here’s your chance. So point your browsers, or RSS readers, or whatever you use to read the internet, over to the Inc. blog and see what Curt and some other notable folks have to say on technology and how it affects business.

Begin the incredible voyage at: http://journyx.com/rss/redir/inctechblog.html

• Can I tie leave and time off requests to an employee’s assigned timesheet approval process?
• What is the standard process for changing an employee’s timesheet reporting period (i.e., from weekly to bi-monthly)?

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

We all know that a project is a temporary endeavor. All projects have some start and end date. However, when I teach project management training classes I like to ask the participants exactly what they consider to be the end of a project.

After some discussion, we realize that there are many candidate events that could signify the end of a project and, in most organizations, the definition is not consistent.

One idea is that an end-of-project meeting could mean the project is officially over. Although ending the project at the end-of-project meeting helps a little bit, it doesn’t answer the total question, since you still need to decide when to schedule this meeting. You could hold the meeting after a number of events, for example after you go live or 30 days after you go live. The ultimate definition of project completion is not resolved by this answer.

The second definition that doesn’t help is that the project ends when the money runs out. Although in many projects, this is actually true, it doesn’t help you in terms of the basic definition. Ending a project when the budget runs out is a financial answer and it is highly arbitrary. It doesn’t answer the more fundamental project management question of how to define the end of a project.

There are a number of events that could signify that a project has ended…

How do I end thee? Let me count the ways at: http://journyx.com/rss/redir/zdni-projend.html

There is no mystery as to why projects succeed or fail; people have been writing about effective project management for millennia. More than 2,000 years ago, Sun Tzu described how to organize a successful, highly complex project (a military campaign) in The Art of War. Fred Brooks’ classic book, The Mythical Man-Month, offers management advice targeted at running large IT projects. The U.K. National Audit Office recently published an excellent guide to delivering successful IT-enabled business change. Over the past 10 years, virtually every major IT publication has printed articles on why large projects succeed or fail.

Despite all the excellent advice available, more than half of the major projects undertaken by IT departments still fail or get canceled. Stuart Orr, principal of Vision 2 Execution, reports that less than 20% of projects with an IT component are successful, with success defined as being delivered on time and on budget while meeting the original objectives.

We know what works. We just don’t do it.

Projects fail because people ignore the basic tenets of project success that we already know. Here are some of the common reasons - and there are many - for failure…

Do the right things at: http://journyx.com/rss/redir/cworld-12things.html

For many years I’ve used this forum and others to fret about the decline of IT as an engine of innovation and competitive differentiation. For those of us who love the job more than the title, love to design and code systems more than plan budgets and write performance reviews, it’s been painful watching hundreds of ersatz CIOs, transferred in from other departments, chop off bits and pieces of IT and throw them overboard. Sadly, most IT departments are now tasked with coordinating the installation of somebody else’s software and negotiating contracts with outside companies to keep systems running on networks that are being monitored by yet another collection of third parties. For most CIOs, this voluntary and catastrophic loss of internal capability is worth the comfort of knowing that they need not worry about a shortage of IT talent and that keeping up with everybody else is simply a matter of being skilled in contract negotiations. As a result, most IT departments are now staffed by people who know how to work things but don’t know how they work.

Read more at: CIO

While I have been working as a project manager on large-scale ERP-related endeavors for quite some time already, I recently asked myself whether the job of the project manager really is that different from the job of a general (line) manager.

If the differences are rather marginal (as I actually do hypothesize) then I am asking myself why we as project managers are in dire need of competency frameworks and the like, if general managers actually perform their job decently well without such frameworks. Or is it fair to say that general managers would do way better on the basis of a formal management framework?

To make a long story short, are you aware of any (academic) work that has been done in this regard, for example:

* Comparing the roles of (identifying the differences between) project manager versus general manager,
* Comparing the efforts of managing a going-concern versus a project, or alternatively
* Comparing the functional domains (Scope, People, Contracts, Procurement, Risk, etc.) to be managed by a general manager versus the ones to be managed by a project manager

Read Max Wideman’s answer at: MaxWideman.com

Have you ever noticed that IT guys are grumpy? Partly I think that’s because they never get calls like this:

“Hey Scott, just called to say everythings working ok today and you’re a great guy!”

The calls are typically more like this:

“Hey Scott, Have you ever noticed that your spam filter pretty much only filters out our sales leads? But luckily it does let all the Viagra ads through which is good because it gives us something to think about while we’re not selling anything. Did they have classes in spam filtering at the college you supposedly went to?”

His only possible answers to this tirade are either:

1. “Shut up.”
2. “Colleges don’t teach that, unfortunately.”

It’s kinda like being a fireman. You can never respond to the fire fast enough no matter what you do.

Read more at: Inc.com