Project Management Blog

Project managers understand how critical the need to streamline all their project’s activities really is. The only way to reach milestones on time and ensure key deliverables are achieved is to build efficiency into every step of the system. So why do so many project managers, especially those in small and mid-sized businesses, rely on outdated technology that isn’t interoperable?

The pain of different technologies

Disparate systems that can’t communicate with each other quickly become bottlenecks in any system, slowing the entire process. These systems cause undue hardship on the project’s contributors, increasing the effort needed just to make simple things work. Fighting to make dissimilar technologies talk to each other takes time and money. It can cause delays that may contribute to missed deadlines, faulty deliverables and possibly even lead to the downfall of the entire project. There has to be a better way.



The ERP solution



Large companies already know about ERP. ERP stands for “Enterprise Resource Planning.” A properly-executed ERP solution unifies all business functions, creating efficient, streamlined processes. It promotes effective implementation of business technology, including project-related applications, by unifying a company’s platforms. Applications in an effective ERP system share a similar interface and a common database. This benefits project shareholders and all employees by giving them a common, familiar interface to use during their project-related activities. This cosmetic change is only the beginning, though.



A common data set



Where ERP shines is on the database side of things, where all levels of the business and all project participants share a common set of data. To fully appreciate this, consider the following example. The project manager reorganizes deliverables, affecting the need for raw materials. The ordering department is automatically updated and can order these assets right away since their data set was altered by the project manager’s actions. As soon as the stock department inventories the new materials, manufacturing becomes aware of their presence and can get to work fabricating the product. This type of information sharing greatly increases the efficiency of any project and will help all businesses, not just the enterprise-sized companies.



ERP and small businesses

Many who know about ERP assume it doesn’t scale, is expensive and can only be applied to the largest companies. This just isn’t true. A growing number of small and mid-sized businesses are relying on ERP products and firms like Syntax's JD Edwards consulting to implement scalable, efficient ERP solutions to help them get the most out of projects and all business activities. There is no need to surrender efficiency and let your projects suffer just because you’re not one of “the big guys.” ERP consultants can help implement an a la carte solution to cover the needs of businesses of any size and on any budget. These ERP applications can be purpose-built to suite the exact needs of the organization and its specific, project-related needs. With a familiar feel, methodology for bridging departments and shared database solution, a scalable Enterprise Resource Planning solution is exactly what any small business needs to implement effective project management better than ever before.

With all the talk of managing projects via Twitter, web-based tools, and more collaborative/social mediums there is still a lack of wide-spread adoption of PM/PPM management tools at many organizations. Many projects still cobble together some Excel spreadsheets, static MS Project file, and MS Viso schemas into a PowerPoint presentations. Version control, standardization, collaboration, real-time updates, etc are all so close yet so far away!

Source: http://kellycrew.wordpress.com/2011/01/10/top-10-issues-for-project-managers/

The sheer number of tools - both good and bad - is daunting.  We'd like to think our tool of choice - web2project - solves all of them but there's still No Silver Bullet.

While on the train heading to Paul Graham's Startup School, I brought along quite a bit of reading material. I was hoping to sleep, but I was also hoping to catch up on some reading while I couldn't be distracted with various tasking, email, etc, etc.

For example, the first thing I read was an article on "Software Development Cost Estimating" and I dug into it with interest. I happen to have a very particular way that I do my estimating - which seems to be quite accurate by the way - but I'm always looking out for more and better methods. This wasn't one of them... let me analyze this one step by step.

In the September/October issue of IEEE Software, I came across an article titled "Why Context Matters" which gets to the difference between functional and non-functional requirements and how the two interact and are interdependent.

Functional requirements are normally taken to be those hard and fast rules like "the speedometer must accurately report speed to the user." Everyone in the industrialized world has a pretty solid idea of what it should do or how it should work. Therefore, there isn't much room to wiggle.

Non-functional requirements are much more "squishy" and open to interpretation of the people capturing the requirements, the users, and those actually implementing the functionality. A rule like "the speedometer must report speed in an easily discernible manner". Wow, now we have lots of room to wiggle, which way do we go?

This is where the Context comes into play.

Over the weekend, I was discussing a couple projects with the highly esteemed Nola who happens to work with me over at CaseySoftware and a regular contributor to CodeSnipers. She was putting together an estimate for a company on a complete site redesign and functionality upgrade and was having problems putting together a solid estimate. In the meantime, I was in the thick of putting together a pair of RFP responses, so I thought I'd share my tactic for getting solid estimates:

Break everything down to the smallest steps/pieces you can.

This weekend, I picked up my issue of the IEEE Spectrum which they've devoted to software failures and started reading the fascinating article: Who Killed the Virtual Case File? It details the FBI's failed Virtual Case File System from its start to its mind-numbing $170M collapse into a steaming pile of unusable code, 800 pages of recommendations, and quite a few destroyed careers. It's absolutely stunning with respect to poor project management, so I'm going to focus on this article for a couple days to lay out where some of their biggest mistakes were and potential ways the risks could have been mitigated.

About halfway through the article, this quote floored me:
Mueller blamed himself for the delay, because he'd asked for an accelerated schedule. But Higgins blamed Mueller's staff for not being straight with him about his agency's ability to deliver what he wanted.

"Did somebody come to you and say, okay, Mr. Director, sir, you can have it sooner, but it's going to cost you this much more money or you're going to have to do without something?" Higgins remembered asking Mueller. "And he said, 'No, nobody ever told me that.' And I said, 'Well, lesson No. 1: faster, cheaper, better. Pick two, but you can't have all three.'

Wow.

In order to build this site into an open clearing house on Project Management related information, I'm putting out an open call:

If you know of *any* great sources on Project Management - books, websites, people, newsletters, magazines, etc - please let me know. I have just activated the Technorati and Del.icio.us aggregators which will be available to all. Information on companies, vendors, tools, books, etc is welcome, but all references should be *relevant* to topics associated with Project Management and should not be sales pitches.

This is a community site, let's get going.

Yesterday, I offered some points about What Project Management is Not and I promised to tell you what Project Management Is... and away we go:

Project Management is a seatbelt.

Just like a seatbelt, a good set of Project Management practices and a good plan won't do much if you're caught in a catastrophic situation. For the minor fender-benders and even bigger problems, it will definitely assist, and potentially provide some safety measures and even an escape route or two.

Project Management is a sign of something more.

Going back to the seatbelt analogy, if you put on your seatbelt as soon as you get in the car, I *believe* (no quantitative data to back this up) that you are more likely to be a safer driver. If you habitually perform good project management practices, you will be more likely to detect problems early and have a response plan in place.

Project Management is required.

For any project that involves more than a few hours of effort, some sort of planning is needed. The planning required is directly proportional to the size of the project. If the project consists of writing a new report this afternoon, the "planning" might be 5-10 minutes to think about it. If the project is version of your system, the planning will involve more people and more time. If the project is a $170M system for a major government agency, the planning will involve representatives from numerous meeting repeatedly throughout the lifecycle of the project.

Project Management is about sharing information.

Personally, I don't care if you use a text file sitting out on a shared drive somewhere. There are better tools available, but the point of all of them boils down to making information available to the required people at the required time. It doesn't matter how great your tools are if the decision makers can't get at the information they need.

Project Management is purposeful.

At some point in every project, a decision will have to be made that others are not going to like. In order to have credibility for cutting features, requesting more resources (time, money, people, etc), or pushing back against requirements, the information needs to be available to state unequivicolly "If we do/don't do X, the project is going to suffer in area Y."

Project Management is ongoing.

von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know that last point is a repeat from yesterday, but it bears repeating. Just because you have a pretty Gantt, PERT, or Critical Path diagram on the wall means precisely nothing. As soon as the project begins, there should an evaluation of your Estimates vs your Actuals. Maybe your estimation technique was off, maybe a supporting vendor moved faster/slower than you expected, or maybe a new product is replacing some of the planned work.

If you're not regularly reevaluating the plan, you're not managing... you're coasting.