Journyx Project Management Blog

CIO published the findings of a Forrester Report in a new article, “The 10 Key Capabilities of Next-Generation Project Managers.” Forrester interviewed IT and project management professionals in order to learn what the future of project management will look like. Here are the top 10 capabilities they found:

1. Emotional Intelligence
2. Adaptive Communication
3. People Skills
4. Management Skills
5. Flexibility
6. Business Savvy
7. Analytical Skills
8. Customer Focus
9. Results-Orientation
10. Character

Another important finding is that project managers must be willing to embrace agile methods in the future in order to keep up with IT and software development trends. According to Forrester Analyst Mary Gerush,

In an Agile software delivery environment, the traditional command-and-control approach of project managers is counter-productive. [...] Instead of defining roles and making sure team members are following project management processes and procedures to a T, next generation project managers need to focus on improving collaboration and removing obstacles and distractions so that project team members can get their work done on time and on budget.

For more information on how to integrate agile and project management, check out the newest article by our CEO, Curt Finch, entitled “How to Create an Agile PMO.”

Okay, so we’ve talked about giving to your colleagues, your customers, and to other companies through the products or services you provide. Can anyone think of something we might have left out this holiday season?

How about giving yourself a gift for all the hard work you did all year?

It’s called PTO, and we all have it (hopefully!). If you take your vacations like good girls and boys, this message is not for you. It is for the workaholics out there who check their work email from home, get in early and stay late and never take time off. This may seem like a great way to advance your career and help your business, but in reality, all you are doing is setting yourself up for burn-out, and fast.

Whether you are about to get all of your 2009 PTO upfront in January, or you have some left over from this year, do yourself a favor and take a few days off. I’ll bet the people you work with will thank you, because a rested you will be much more pleasant to work with.

- April Boland, Journyx Communications Coordinator

Much has been written about the need for IT to develop a deeper understanding of business. For the past decade, CIOs have been urged, coaxed, counseled and exhorted to act more like CEOs, chief financial officers (CFOs), chief operating officers (COOs), and other C-level executives.

I’m not going to argue about the wisdom of that advice. But I’m going to suggest that it’s only half the story. The other half, the piece that is usually missing from conversations about innovation, competitiveness and the opening new markets is this: It is time for business to learn more about IT.

Read the rest at CIO.com.

Top programmers are not easy to find. It takes time to cull through dozens, if not hundreds, of resumes to find the magic combination you want, and it takes hours to perform interviews. After all of that, you still need to jump through hoops to make sure that your best candidates accept your offer rather than someone else’s.

Yet all too often, these hard-to-find (and hard-to-hire) employees are neglected once they come on board. While proper compensation is, of course, a large part of employee retention, the top programmers need more than a great pay check. Here are 10 reasons why your star programmer might be looking to leave, and what you can do to convince them to stick around.

#1: Poor pay
No one works purely out of a charitable nature. So when your best people feel like their pay is severely out of line with market standards, they may start to view other pastures as being much greener than yours. Your worst enemy in retaining the stars is the thought, “I am the worst paid senior developer in this town.”

I see a lot of companies that look at what the market is like only when they hire someone. Meanwhile, your best people are often aware of what is happening in the market consistently. If you have not re-evaluated your pay packages in a while, you need to. While the package may have been competitive when you hired someone three years ago, your best employees may be able to get a substantial raise by making a lateral move (if not taking a higher level position) to another employer.

#2: An uncertain future
The best people often have no intention of leaving until something out of the ordinary prompts them to stick their toes in the job market waters. At one company where I worked, the trigger for a mass exodus was the sale of the building our employer was renting to a major company that obviously was not going to keep leasing to us. A lot of people panicked and wondered whether the loss of the office space would prompt a move of the operation to another city. Instead of sitting around waiting for the other shoe to drop, they left. At another company where I worked, a large layoff spooked those who survived, and they left as soon as they could.

There is little you can do to prevent these outside influences from occurring, but you can do a lot to reassure your people when they do happen. Your best programmers are not dumb; they know when you are trying to puff them up with hot air instead of being forthright. When these events happen, give your people the straight truth and show them what you and the company are doing to prevent the need for your stars to lose their jobs. It’s a tough path to walk, but too many managers cave in to the temptation to cover up the problems — and those cover-ups tend to drive people out even faster.

Read the rest at TechRepublic.

The original deadline for our software project had come and gone, and every week the new finish date was sliding farther into the future. The Vice President of Development decided that he needed to call a project summit meeting, bring the finish date in sooner, and nail down a schedule once and for all. He called all the important managers (but none of the programmers) into a room. They shut the door and vowed not to emerge until they had shortened the schedule.

One of the managers laid a rock on the table, solemnly turned it over, and said they should “leave no stone unturned” in their effort to shave time off the schedule. They re-examined each task in the project list, shortened many of them, made some tasks concurrent, and eliminated a few others. They emerged several hours later with a tightened schedule, and an earlier end date.

All the managers were happy. They had accomplished their goal of shortening the schedule.

In hindsight, it is not surprising what happened: The managers’ effort was a waste of time. The new schedule had no effect on the pace of development at all. The project was finished at the about the same time it would have been, except that five or six highly paid resources wasted a half-day looking at a rock in a room.

Read more at Developer.com.

The senior White House IT official, Karen Evans, said she believes software as a service (SaaS) can improve government IT projects and systems.

Evans made her remarks during a talk at the Saas/GOV 2008 conference. From InfoWorld:

“Our track record is clear — we are not very good at delivering our own software in the time frame set,” Evans said at the conference. “We’re also not very good at managing large projects.”

Some agencies haven’t embraced the service approach, often because they want hands-on control of software development, Evans said. But government agencies can’t afford to keep developing their own software without sharing with other agencies, she said.

“We can’t continue to maintain all of the things we have,” she added. “We have to start shutting down some of our legacy systems. We really have to move to a … service-oriented market.”

Read more at IT Project Failures.

In this article, I will try to tell you a way you can tackle one aspect of a project—software estimation. I will tell you how I estimate projects and the geometry involved, and if unfettered by poorly judged external forces this way leads me to a successful delivery. But, the most important thing is that these are general guidelines and there is simply no substitute for individuals and teams that can succeed in their own way. Individuals and individual teams must be permitted to use their own judgment, for there is no more desirable outcome than a delivered and well received product. (Until software becomes an assembly-line process and by then, God willing, I’ll be horizontal.)

Geometry

Geometry applied in the context of software development project estimation refers to the size, shape, and relationships among all of the elements of a software project, including those practices whose direct result are tangibles and those time slots that are essentially intangible but necessary in some way. Many estimators get some of the tangible parts of estimation correct, but it is all of the intangible aspects that are often overlooked and result in delays, disappointments, and undelivered software.

Tangible elements (often called deliverables) can include project plans, requirements, detailed designs, the software, and time spent testing, debugging, documenting, and launching software. Many people know about these elements and some include these elements in estimations. Sadly, some do not include all of these elements. Intangibles such as water cooler time, illness, bad requirements, wrong requirements, changed requirements, unforeseen hard bugs in your code or the tool provider’s code, learning, white board time, unit tests, arguments, meetings, distractions, failed or replaced hardware, absenteeism, car accidents, sustainable productivity levels—getting in and staying in “the zone”—reading FoxNews.com, checking out research.microsoft.com and more, are all too often overlooked, dismissed, or denied. But, these are the elements as likely to happen as coding that chew away at the schedule, willingly or not, and is what is most often overlooked in a project schedule. To account for the tangibles, methodologies like RUP were invented. To account for intangibles, methodologies like XP and Scrum were invented. But, again there is no substitute for having people who have demonstrated an ability to deliver.

Tip: Software projects that succeed often have a single-minded determination and focus on the number one deliverable, the software.

Read the entire article at Developer.com.

Quality in software development projects doesn’t happen on its own. It also doesn’t occur after a small group of heroes rides in on white horses and waves its shiny swords to vanquish the problems. Quality happens only when careful planning is done, when the entire project team maintains a quality-conscious approach every step of the way, and when problems don’t escape from the phase in which they were introduced. A quality product is a team effort. It’s planned and predictable. It’s without heroes, and it’s faster and cheaper than a low-quality effort.

How can this be? Let’s look at some sample projects. The first is a normal, low-quality, late project. We’ll call it project “Hurry Up” (HU for short).

Project HU got a bit of a late start due to the ongoing maintenance issues of its predecessor project “Just Ship It” (JSI). JSI was handled by a project manager (PM) who felt it was more important to ship on time than to ship a high-quality product. So he did. This PM was rewarded for his ability to “pull it together,” “get it out the door” and “meet the schedule.” The JSI PM was given a bonus for meeting his schedule and is now vacationing in Tahiti while the team deals with the fallout of the numerous bugs and unhappy customers.

Lesson #1: Don’t reward for shipping on schedule. Anyone can ship garbage. Base rewards on quality metrics.

During the last month of the project, the JSI developers worked 80-hour weeks. One heroic fellow was recognized for working 120 hours in one week, stopping only for brief rests. He heroically repaired multiple interfaces between applications. Those interfaces had not been properly specified (there were no design documents), no integration testing was done (no time to do it), and the QA team fought quality issues throughout system test.

Read more at CIO.com.

Productivity and software quality are topics of perennial interest to IT professionals. Measuring quality is a fairly straightforward process after all, defects are easily countable. But productivity is not so easily quantified. As a result, productivity metrics vary.

Productivity is often expressed via ratio-based metrics like lines of code per staff month or hours per function point. While useful, these measures have one significant limitation: they don’t account for the time frame in which the software is developed. Essentially, they measure cost efficiency rather than the time to market. Unfortunately, it serves little purpose to excel at technical productivity (e.g., saving money) if you miss a marketing window.

So, how do we define productivity, and where do we get the information? Quantitative Software Management, Inc. uses its SLIM software tools and consultative approach to capture the management numbers that enable organizations to effectively estimate, track, and benchmark their software development and maintenance projects. The company maintains a database of some 7,000 completed projects. The data in this article is taken from the QSM Software Almanac: Application Development Series. Organizations submitted data from 536 IT projects sampled from 31 companies in 16 countries, including 16 industries and nine sub-sectors, ranging from Aerospace to Financial IT.

Read more at: Project Times

In a recent blog, Nicholas Carr writes that “large companies appear to be jumping en masse onto the software-as-a-service bandwagon, according to a new survey of CIOs by management consultants McKinsey & Company. The survey found that 61 percent of North American companies with sales over $1 billion plan to adopt one or more SaaS applications over the next year, a dramatic increase from the 38 percent who were planning to install SaaS apps in 2005.”

This conclusion should not surprise anyone who’s been watching the sales increases at Salesforce.com or the growing traction of newer SaaS players. What’s significant is not that SaaS is growing, but that SaaS is gaining acceptance within businesses that rejected SaaS only a few years ago. Indeed, I remember a meeting at a particular company back in 2003 when I was told that “We will never use an application we don’t own.” In 2006 that company implemented three SaaS-based applications. So, I guess you should never say “never.”

In addition to the data points from the study Carr cites, other industry analysts are coming to the same conclusion

Read more at: The Intelligent Enterprise