Cigarettes have a way of bonding people together.  In offices, in schools, in public places smokers hang-out together. They form connections bumming cigarettes, getting a light and sharing stories of being an outsider, a smoker, with fellow travelers.

As there are smokers and non-smokers, smoking sections and the rest of the world, it seems that cell phone users are becoming the new smokers and cell phones the new cigarettes.  Not to be too Carrie Bradshaw but recent stories report authorities in offices, schools and public places are restricting the use of cell phones. They are designating the times, places  and how cell phones can be used.

Take this story from The Current (a news show on CBC Radio One) where school boards are taking steps to control cell phone use in public schools.  Will there soon be groups of ’phoners congregating behind bleachers or darkened corners to sneak a call or quick txt msg between class?

Or this story from CNNMoney.com on how annoying cell phones can be, causing distraction, reducing productivity and raising the specter of legal liability for any accidents that may happen while someone’s on the phone at work. Will cell-packing workers be forced to steal away to the nearest stairwell for a fix whenever they feel that phone vibrate or twitch in their pocket?

While the dangers of second-hand cell phone use haven’t boiled to surface, can they be far behind? Already, there is some research linking increased exposure to elevated levels of electromangetic radiation -radio waves, to health problems.

There are clearly instances where distractions can be dangerous (whether from cell phones, kids or otherwise). Encouraging people to pay attention to the road is a good thing. 

But it seems that society is preparing to accelerate the dialogue on cell phones and cell phone users.

Are cell phones the new cigarettes?  This is a question we may all soon be addressing. Will chatter-filled rooms with pinging buttons and top-40 ring tones soon go the way of corner-bars and wood-panelled offices reeking of smoke by 1 pm?

Few things can create more tension in a project than pushing back a deadline. 

It can create instant anger between a project sponsor and the project manager. It can even filter down to the people working on a project. Resources end-up choosing a bad-guy: the project sponsor (”she doesn’t get it”) or the project manager (”doesn’t know what he’s doing”) -while all the while risking being cast as lazy or incompetent because the deadline is being blown.

Often, the source of the anger can be traced to differing expectations on how the project should unfold over time. 

Both the sponsor and the project manager likely realize that nothing ever goes as planned, that hiccups happen.  The frustration comes in different expectations on the effect of hiccups.  That is, there are different answers to the question of ”what does this problem mean to my project?”

One side (often the sponsor) expects that a hiccup means that the project will be delivered on-time, but on a reduced scale (less functionality, less features, smaller scope).

To the other side (a classically trained project manager, say) a hiccup means that the project will be delivered as planned, just later.

This dichotomy in expectations mirrors a central difference between two major schools of project management methodology. The two schools are Agile project management and the classic Waterfall approach to managing projects.

Understanding this difference can help pin-point the source of frustration on projects when a deadline is missed. 

By using the language of Agile versus Waterfall people can more clearly explain where they’re coming from at the start of a project -and hopefully reduce the anger and frustration that can arise in the middle of a project, when the project takes longer than planned.

Agile and Waterfall have different views on the lifecycle of a project. 

• Agile tends to look at a project as fluidly ongoing, evolving through a series of iterations. 
• Waterfall looks at projects as having a defined end-point, the delivery of a pre-specified set of requirements.  

AGILE PROJECT MANAGEMENT MINDSET 

Agile aims to deliver something that can go live, in a relatively short period of time, collect data or feedback, go back to the drawing board, deliver again and relaunch. It keeps iterating until a further iteration is no longer necessary or useful. But throughout the process, at every step of the way, something ”live” is being produced and delivered.

Coming from an Agile mindset, if a hiccup happens, the next iteration gets pushed off. But at least there’s something live that can be worked with.

WATERFALL PROJECT MANAGEMENT MINDSET 

The Waterfall approach starts by spec’ing out everything the final deliverable should be. It begins with the assumption that the research has been done and the data analyzed. The final project deliverable represents the best-guess of what should work to fulfill the goals of the project sponsor. In a Waterfall, the project moves sequentially through its lifecycle, cascading downward from specification, to design, to development/production, to testing and going live. The deliverables don’t exist, even in a rudimentary form, until the production phase is reached.

Coming from a Waterfall mindset, if a hiccup happens, the launchable deliverables get delayed, the whole project gets delayed, until the hiccup is resolved.

REDUCING FRUSTRATION

Both Agile and Waterfall have their place in getting projects done.  

But for the purposes of reducing frustration and anger on a project, they are only useful tools to raise awarness of differences in people’s expectations -differences that are the source of tremendous tension.

This awareness can facilicate healthy communication, and reduce the source of frustration before any problems arise. When a problem does arise, the project sponsor, project manager (and even the team) can be on the same page as to what to expect.

Everyone can have the same answer to the question “What does this problem mean to the project?”

By the way, it doesn’t matter if  people know the difference between Agile, Waterfall or the Bay Bridge -if it complicates things, or requires more explanation that its worth, leave the fancy terminology out. 

The important thing is to talk about the differences in expectations on project lifecycles that can and often do exist.

Came across this post bemoaning the state of collaboration features available in enterprise content management solutions.

Our approach in Vertabase Pro is to offer collaboration and content management within the framework of doing projects (and using project management tools to accomplish and manage the projects).   

What do you think of this approach?

After taking a look at the software, what recommendations or suggestions would you have for the content management component of the software? 

Note: you can check out the software by clicking here. The content management features are in the Document section of Projects.

Here’s a review of MS Project 2007 project management software from one of our Vertabase Pro users. The review focuses on the interface of the software.

To attempt to contain complexity, MS Project 2007 introduced Ribbons — a pane that contains controls (such as buttons and icons) that are organized into a set of tabs, each one containing a grouping of relevant commands.  This type of interface replaces traditional menus and toolbars.

The Ribbon is “all about making the software do what you want to do,” as they state in their literature.  This Ribbon will also be incorporated into Microsoft Office 2007 as a main new feature “Replacing the menus and toolbars that have been the cornerstone of Office since its inception.”

While Ribbons consolidate related functionality in one place and can improve usability, they do not solve the problem of complexity. Microsoft Project will still be very complex and time consuming to learn. 

It comes down to design. They are not working from a clean apriori design. It is not targeted to a manager using a system with a team requiring a robust solution that is scalable to multiple projects and tasks but without the complexity and nuance that a professional project manager would require (and feel comfortable with).

No matter what, how the controls of a jumbo jet get automated or are easy to access it is not the right vehicle to travel from the suburbs to downtown. You will still need advanced project management expertise to create, manage and communicate projects plans in Microsoft project – even with Ribbons.

Project management built for an enterprise is generally more robust than mass market project management software.  Almost by definition, enterprise project management software includes two aspects that separate it from general project management software.

• The first is the robustness of feature set.
• The second is the number of users that touch the system.

Features that you’ll generally find in enterprise project management software include resource allocation, project portfolio view, cross project gantt charts, budgeting and potentially a host of advance project management performance metrics.

In terms of users, this type of project management software is touched by a large number of users who’s data differ and who’s background in using project management software is varied. This can range from the project managers who use the enterprise tool every day to executives or upper management who touch the software only occasionally to get updates on particular projects or specific project porfolios.

Historically, most enterprise solutions have had a hard time reconcilling robust functionality and the needs of a varied user group.  Applications like Primavera, Artemis, Planview and MS Project Enterprise Server have long been the domain of specialists.  Companies that tried integrating this kind of software throughout the organization have encounterd  long and costly training sessions with signficant interuption in people’s workflow. More often than not, the software ends up only being used by a small group of project management specialists and a burden on everyone else.

The next generation of web-based, enterprise project management software avoids this problem and increase the use of effective project management in an organization. If you want to see the differences in approaches to solving this problem compare Vertabase Pro and eProject.

Two avenues Vertabase Pro has used for solving this problem have been:

• Making the robust features easier to use and
• Not forcing people to learn the whole software -if someone doesn’t need to use a specific feature, they don’t even see it.

Overall, this has made software which is far less intimidating to implement and more likely to make a positive impact on a company’s workflow. 

Happy 2007 from Vertabase Pro, project management software.  Thank you for a great 2006! Looking forward to a wonderful 2007.