You are here

It's About Time! The Journyx Blog

August 17, 2011

If you live in Texas, you know about SXSW. If you don't live in Texas, chances are still pretty good you know about SXSW. And if you DON'T know about SXSW, you need to stop what you're doing and listen up!

SXSW is the annual music, film, and interactive conference and festival held in Austin. SXSW Music is one of the largest music festivals in the United States, with more than 2,000 performers playing in more than 90 venues around downtown Austin over four days. SXSW Film has become one of the world's premier film festivals, focusing on new directing talent. SXSW Interactive has attracted a strong following among web creators and entrepreneurs. Its focus on emerging technology has earned the festival a reputation as a breeding ground for new ideas and creative technologies. The festival has grown every year, most recently bringing around 15,000 to 20,000 registrants to Austin.

The dates for the 2012 Conference are:

Interactive: March 9–13
Film: March 9–17
Music: March 13–18

Okay, so why am I telling you all this? We need your vote! Journyx CEO Curt Finch has submitted a presentation for the Interactive conference. People can vote on the presentations they would like to see at SXSW for the next 2 weeks. Public votes will account for 30% of the total vote. We would love it if you'd take just a minute and go here to vote for Curt's presentation: VOTE HERE

And if you are planning to attend SXSW this year, let us know in the comments section. We would love to meet you!

August 17, 2011

Ahhh…the age old question. Or at least one that seems to come up from time to time. It’s certainly a question that has frustrated me for a while. When should the project manager become engaged in the project? After the sale? During the sale process? From inception, working right alongside Sales to map out an estimate and close the deal with the client? You could say ‘it depends’, but I’m not sure that’s a good answer either.

About a decade ago I worked for very large aviation and engineering firm where I specialized in managing web projects primarily for internal customers. What that means is I led internet and intranet projects for individual business units within the organization. The whole sales process was mine. There was no marketing involvement, just the internal sponsor initiating a project request which was my cue to find out their needs, map out requirements, and then turn around a price estimate that we could move forward with. I would sometimes take a developer with me to speed up the process of documenting requirements and a proposed solution if I wasn’t completely sure, and that would get me to a good price point quickly for the internal client. None of these were multi-million dollar engagements – the largest was probably close to $100,000. But you can see how informed I was as I assembled my team and began to work with the client on the project. There were no gaps or cracks through which information could fall. I had been with the project from inception and knew everything.

Fast-forward ten years to larger projects I was leading for a professional services organization. The Sales team completes the deal with a price and a proposed solution and starts throwing these projects over the wall to me and the other project managers. We have only the knowledge we can extract from the account manager during a phone call and we have the statement of work…and not much else. No wonder when I showed up at the client site for project kickoff I was usually bombarded with questions and expectations that were different from what I was telling them was going to happen on the project.

It’s extremely important – no, it’s critical – that the project manager be a part of that sales process. There are too many risks involved – including budget and other financial risks – when the individuals who will actually be carrying out the project aren’t part of the team that also prices the project and drafts a solution. The project manager should be allowed to act much more as an engagement manager – running the concept or project request from inception to deployment. When you just hand it over the wall, you create a do-over point where knowledge must again be transferred and you have too much risk for important details just falling through the cracks.

Summary

So I’ll ask the question again, should the project manager be involved in pricing the engagement? My answer is an absolute ‘yes’. And much more than that – the project manager should be involved in the whole account management process of getting the project request to the ‘sold project’ point with a statement of work, price, draft schedule and a date for an official kickoff meeting. By involving the project manager, you have the best chance at not only presenting the right price, but then also ensuring that your project team and the customer will be on the same page when they sit down to finalize how the project will be run during the formal kickoff session.

 


 

About the Author: Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

August 15, 2011

The potential benefits of a project management office (PMO) are numerous and well-documented. However, many of the benefits never materialize. Take a look at PMOs over the years and you will see that many have restructured, dissolved, or constantly had to justify their existence during both economic downturns as well as high-growth periods. This is evidence enough that PMOs are not yielding demonstrable positive financial results. This churn often causes years of frustration for both the PMOs and the projects and departments they serve. Changing the way in which the PMO is chartered, works, and is perceived within an organization can ensure that it offers plentiful advantages for the entire organization.

Two Problem Scenarios… And Strategies to Solve Them

One: The PMO is spawned by an executive with a big problem

Let’s consider this example: a client forms a PMO to salvage a huge contract with a customer. A very large project lags, causing late deliveries and missed expectations all around. Department staff is not completely honest with the customer, hoping that they will somehow be able to ‘catch up.’ They fall further behind and an executive is forced to intervene. Experienced senior project managers are brought in to assist with the problem, turn around customer expectations, and evolve communication and estimation processes within three months. In another four months, the project managers turn the projects back over to a grateful department.

The senior project managers who saved the day wonder, “Now what? We had unrestricted executive access, some of the best people across the organization loaned or transferred to our projects, and spent tens of thousands of dollars on training, equipment, and process improvement. Results were great. Now we can’t get a phone call returned from a director outside the PMO or any attention to the best practices we just proved are necessary to keep projects out of the red zone.” Three of the four project managers are let go or quit within the next six months along with half of the PMO staff of 20.

This example is not just for illustration – it is happening in organizations all across the country every day. If the PMO is helpful in solving the big problem, then PMO staff members must assume other roles to continue to justify their existence. When PMOs define their own course, the high-percentage outcome is stagnated by over-regulation and process. It does not take long for your PMO to lose power and possibly be disbanded.

Strategies to remain financially viable:

  1. Always take on the big problems. Put the PMO on each issue as a fix-it or turnaround weapon.
  2. Key deliverable leave-behinds should include significant process improvements that equip your internal customers with tools they didn’t previously have that make them more successful going forward.
  3. Processes used should include mentoring and training key people in the problem domain so that the fixes the PMO put in place ‘stick.’
  4. Help the involved departments win their battles, shore up their defenses and then move on to the next big problem.

Two: The PMO is spawned by one or more executives who want more visibility or compliance via governance efforts but don’t really want lasting change

Read the rest of this article at PM Hut.

August 10, 2011

Have you ever had that project or account that you just had to have? One that, for some reason, you saw as a make-it-or-break-it client initiative. Do you have a ‘succeed or die’ mentality? It’s probably a good thing if you don’t.

I realize there are times when we say, “I need to get that business or I may be in trouble.” That’s the nature of business. As an independent consultant, I’ve reached that crossroad a few times….I’m sure most consultants do. But do you go at it with that win-at-all-cost mentality? Or do you get creative? I vote for creative. A CEO of one company I worked used the win-at-all-cost approach….and it was not successful.

The Scenario

The organization I was working for was a small professional services company located in the Midwest; I was responsible for leading and growing the staff in Las Vegas. I was responsible for leading projects for one of their gaming/hospitality clients and as well as leading a project to perform a complete re-write of the software system that basically ran a local Las Vegas hospitality firm’s entire organization.

For the software re-write, we determined that the software would need to be completely abandoned as it had become a bad patchwork of software and add-ons. For some reason, our CEO wanted the contract badly and bid accordingly – low enough to win the business. However, we were much smaller than our well-known competition causing the client organization some anxiety. The client CIO felt that we would likely introduce change order after change order to recoup the revenue we were giving up in our winning bid. So our CEO pulled out the showstopper…he guaranteed one price (which was in the $1 million-plus range) and no change orders…period. None. No matter what. Well, that sealed the deal.

The problem, of course, is that it became a budgetary nightmare for me as the project manager because it was priced too low and there was no way to add revenue through change orders. The client was understanding enough, but everything within reason that they asked for, we did. The work was eventually completed, but by the end of the project, it was more than 60% over budget and my hands were tied from finding ways to add any revenue to the project. I know that the CEO’s hope was that eventually more work would come from the customer, but both organizations eventually failed – the client’s from the economy and the vendor (my organization) from poor management and fraudulent tactics by the CEO.

Summary

As a project manager and as an independent consultant, I’ve never been in favor of a win-at-all-cost strategy. The go-for-broke mentality is not likely to win you long-term business and it can certainly cause your financial infrastructure to become shaky by betting everything on one project going perfectly and not breaking the bank.

As we all know, every project hits bumps…every project experiences some sort of issue or critical point. And nearly every project struggles to some degree to stay on budget. Plus, more than 50% of all projects fail to some degree. Putting too much hope in everything going perfectly on a project is a recipe for disaster. It is far better to strategize, and pick projects and clients that match well with your long term organizational plans and financial goals. It’s the best decision to price work to profit, not just to win no matter what. A win-at-all-cost mentality at the top of your organization can bring a company down fast - leaving everyone else to pick up the pieces with the clients you were faithfully trying to serve.

 


 

About the Author: Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

August 8, 2011

I have a new blog launching today on CIO called "Succeeding in the Consumerization of IT." Hope you'll add it to your favorite blog reads. Here's my first post...

Let’s go back to the early 80’s...

When I was in my 20s, I worked in the computer lab of Babcock & Wilcox. I thought the Apple Macintosh was the coolest thing I’d ever seen; the first successful PC to use a Graphical User Interface. IBM’s PC was gaining traction among the workers at B&W. The rise of the PC was just beginning in the early 80’s, and it was starting to trickle into the workplace.

Back then, an employee’s computer was provided by the company and the head of IT was responsible for providing and maintaining it. Suddenly, with the awareness of the possibilities of a PC, the B&W IT head kept getting requests from workers to have their own PCs at their desks all the time. Not only that, but the employees wanted IBM or Apple, the most popular PC systems at the time. The head of IT, however, insisted that B&W keep up its relationship with Digital Equipment and instead provided all employees with Rainbow PCs.

The Rainbow PCs did not go over well among the employees. The Rainbow PC wasn’t made with pre-installed applications like the IBM and Apple PCs. The Rainbow 100 simply wasn’t designed with what users were starting to get used to in the computer market. The breaking point came when a company lawyer, in a fit of frustration, threw his Rainbow PC in the trash and proclaimed to the IT head that he was never using the Rainbow again. From then on, the lawyer brought his own IBM PC from home to the office. Soon after, the rest of the company brought in their own PCs and abandoned the Rainbow PCs altogether.

That was the first time I saw the crowd overrun the IT Department. Unfortunately, I had no idea that the incident with the company lawyer had happened when I suggested to the IT head that the company provide Macintoshes to all employees. His face got very red in anger and he said, “Nobody wants to use a graphic user interface! People are offended by that graphical stuff! They think it’s condescending, like they’re being treated like babies. Everybody wants to use command line!” And being the sarcastic kid I was, I replied, “Sure they do.” (What can I say? I was a punk.)

Read the rest of the article here.

August 5, 2011

The following article excerpt comes from Project Times.

Many of the clients we work with are a “PMO of one.” Usually this person has been brought in to establish common processes and procedures around planning, managing and executing projects. Most often, there is a broad spectrum of project work being performed by varied project teams within the organization, including a range of maturity levels spanning from no established, repeatable processes to very formalized and documented processes.

According to the Project Management Institute, “Companies with greater maturity should expect to see tangible benefits that include better-performing project portfolios, efficiencies that come with better resource allocation, and increased process stability and repeatability.” [i] On the other hand, companies that are less mature tend to be reactionary, trying to dodge problems as they come rather than strategically planning and executing projects. Often, these companies have various groups working in their own silos, so there is no centralized view of resource availability or up-to-date project status. Project managers are consequently unable to prioritize projects or schedule them with accuracy. This can lead to lost opportunities and failed projects time and again. A new study on organizational maturity has confirmed the need for defined repeatable processes, finding that companies that use them have a much higher project success rate than those who do not.

So how can the “PMO of one” bring teams and processes together to get everyone on the same page, speaking the same language and doing things in similar ways? Here are some things to think about for establishing common project processes that can be adopted throughout the organization, providing better performance and tangible results.

Focus on the Critical Business Issue

There are a number of reasons why an organization would decide to unify its project management processes. It could be a response to client pressure, a desire for an additional competitive advantage, or part of the general evolution of the company. Other times, the lack of organizational maturity is leading to lost opportunities. Understanding the reason behind the shift will not only give you direction as to how you should approach it, but can also help project managers to find creative ways to address the issue.

Don’t just establish processes for the sake of establishing processes. Rather, let the fundamental issues you’re trying to address or avoid drive your direction. You might find, for example, that re-engineering your processes isn’t what you need at all. Perhaps providing increased transparency, visibility and collaboration around all of the projects across the organization better addresses the critical business issue.

Read the rest of this article from Project Times here!

August 5, 2011

The following article excerpt comes from Project Times.

Many of the clients we work with are a “PMO of one.” Usually this person has been brought in to establish common processes and procedures around planning, managing and executing projects. Most often, there is a broad spectrum of project work being performed by varied project teams within the organization, including a range of maturity levels spanning from no established, repeatable processes to very formalized and documented processes.

According to the Project Management Institute, “Companies with greater maturity should expect to see tangible benefits that include better-performing project portfolios, efficiencies that come with better resource allocation, and increased process stability and repeatability.” [i] On the other hand, companies that are less mature tend to be reactionary, trying to dodge problems as they come rather than strategically planning and executing projects. Often, these companies have various groups working in their own silos, so there is no centralized view of resource availability or up-to-date project status. Project managers are consequently unable to prioritize projects or schedule them with accuracy. This can lead to lost opportunities and failed projects time and again. A new study on organizational maturity has confirmed the need for defined repeatable processes, finding that companies that use them have a much higher project success rate than those who do not.

So how can the “PMO of one” bring teams and processes together to get everyone on the same page, speaking the same language and doing things in similar ways? Here are some things to think about for establishing common project processes that can be adopted throughout the organization, providing better performance and tangible results.

Focus on the Critical Business Issue

There are a number of reasons why an organization would decide to unify its project management processes. It could be a response to client pressure, a desire for an additional competitive advantage, or part of the general evolution of the company. Other times, the lack of organizational maturity is leading to lost opportunities. Understanding the reason behind the shift will not only give you direction as to how you should approach it, but can also help project managers to find creative ways to address the issue.

Don’t just establish processes for the sake of establishing processes. Rather, let the fundamental issues you’re trying to address or avoid drive your direction. You might find, for example, that re-engineering your processes isn’t what you need at all. Perhaps providing increased transparency, visibility and collaboration around all of the projects across the organization better addresses the critical business issue.

Read the rest of this article from Project Times here!

August 3, 2011

Social media is certainly something we hear about every single day, isn't it? I mean, you're reading this on a blog right this minute! If your company is not engaging in social media, it's time to jump on board.

NetProspex, a company that helps B2B companies discover and connect with millions of targeted sales prospects, has put together a very comprehensive social business report. According to them, it is "a comprehensive report on the use of social media by business people across the US."

The report, available for free download here, covers the following areas:

Background
Methodology
What’s New in Summer 2011
20 Most Social Jobs
10 Least Social Jobs
Top 20 Jobs on Twitter
100 Most Social Companies
Top 50 Companies on Twitter
50 Most Social Industries
10 Least Social Industries
Top 50 Industries on Twitter
50 Most Social Cities
10 Least Social Cities
Top 50 Cities on Twitter

Go ahead, take a look! And then report back here on what you learned!

August 3, 2011

Social media is certainly something we hear about every single day, isn't it? I mean, you're reading this on a blog right this minute! If your company is not engaging in social media, it's time to jump on board.

NetProspex, a company that helps B2B companies discover and connect with millions of targeted sales prospects, has put together a very comprehensive social business report. According to them, it is "a comprehensive report on the use of social media by business people across the US."

The report, available for free download here, covers the following areas:

  • Background
  • Methodology
  • What’s New in Summer 2011
  • 20 Most Social Jobs
  • 10 Least Social Jobs
  • Top 20 Jobs on Twitter
  • 100 Most Social Companies
  • Top 50 Companies on Twitter
  • 50 Most Social Industries
  • 10 Least Social Industries
  • Top 50 Industries on Twitter
  • 50 Most Social Cities
  • 10 Least Social Cities
  • Top 50 Cities on Twitter

Go ahead, take a look! And then report back here on what you learned!

August 1, 2011

As project managers we run our projects, oversee our project teams, interact with our customers and try to get everyone focused on the tasks we’ve assigned them. From a financial standpoint, we forecast our expensive personnel resources for the life of the project – how, when and where we’re going to use them – and that becomes part of what we roll into our budget forecast. All of that is – or should be – our responsibility. No questions there.

But invoices? Follow-up on billing issues? Really? I have four other projects to manage and now I should handle billing and invoicing issues, too? You have to be kidding! Isn’t that something Accounting should be handling? It’s their job! Umm…no. Actually, there’s no one better to interact with vendors and customers on the project than the project manager if any potential financial issues arise– even if it does add extra effort to your already overloaded workday.

Customer example

Not long ago, I was managing 6-7 projects concurrently for an organization and one was an inherited project with ongoing issues. There were already some issues with customer confidence and satisfaction. The VP of professional services called me one evening to let me know that this customer – a very large government entity – had not paid its invoices in three months. This was a time when large government entities still had lots of money to spend. It looked like a billing issue, smelled like a billing issue, so it must be a billing issue. He asked me to take care of it. I called the project sponsor – who I spoke with regularly, just not about invoicing issues. It turned out to just be an oversight, but it was a good discussion to have and it actually opened a new channel of communication between the project sponsor and myself, which helped the project going forward. The focus on the budget focus and payment on invoices – which were sizeable on a monthly basis because of the work my team was performing – remained consistent for the rest of the project. That consistency of bills being paid on time kept my senior management happy.

Vendor example

Another project – also working with a large government entity –encountered invoicing issues. This time it was with a third party vendor who was my independent tester on this project. This was something required by the government contract because the data was sensitive and the project was so large (tens of millions of dollars). My project was being billed incorrectly – overcharged – by our third party vendor (accidentally with no mal-intent).

The only way I found out about this was through a casual question that Accounting brought to my attention. Had that question not come up, Accounting would have continued to pay the incorrect invoices and I would have had an ongoing budget issue with no real understanding as to why. And curing it up later in the project would have been much harder than midstream. This way, I could work with the vendor to correct it retroactively as well as going forward.

Summary

The bottom line is, as project managers, our responsibility for the project is everything. We can say this department takes care of this and that department takes care of that but at the end of the day, if something is amiss, it’s on us. We have to involve ourselves in every aspect of the project and not assume that someone else cares as much about the project and its well being as we do. Get involved. Know someone in Accounting. Befriend the account manager in Sales who sold the maintenance agreement to the client. Get close to the primary tech support contact for your project. Don’t leave things to chance. If you help to make sure all of the bases are covered, then they probably will be covered. And you’re less likely to have a big financial issue or surprise waiting for you at the end of the engagement.

 


 

About the Author: Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

July 29, 2011

Janis Rizzuto is Contributing Editor of ProjectsAtWork. We loved her latest article on Agile where she interviews Scott Ambler, chief methodologist for Agile and Lean with IBM Rationaland. We wanted to share a summary with you here. Head over to ProjectsAtWork for the full article.

Looking to learn from someone with a consummate résumé in the agile space? Look no further than Scott Ambler. Ambler is chief methodologist for Agile and Lean with IBM Rational, working with customers around the world to help them understand and adopt software processes that are right for them. He is the founder of the methodologies for Agile Modeling, Agile Data, Agile Unified Process and Enterprise Unified Process, and the creator of the Agile Scaling Model. His latest work is around Disciplined Agile Delivery, which he describes as “people first, learning oriented and enterprise aware.”

A prolific author, Ambler has received awards for several of his 19 books, and he is currently a senior contributing editor for Dr. Dobb’s Journal. In the electronic publishing world, he has a blog on the IBM site, Agility@Scale, and a personal website with deep resources on agile methods and trends.

ProjectsAtWork tapped his expertise to provide a view of the current and future state of agility. His key message: Scaling agile to the enterprise is essential.

You attended the anniversary meeting for the Manifesto for Agile Software Development. What was your impression of the event and its significance?

I thought it was a bit too short. We needed another half-day. This year’s group was more diverse than the original group who authored the manifesto 10 years ago. People discussed their experience with what is working and what is not working. There were a lot of good ideas. I hope we will do it again and not wait 10 years.

Reflecting issues for Agile’s future, four belief statements were written at the meeting. Does any one of them matter more than another?

Yes, the statement to “maximize value creation across the entire process” is the most important to me. It reflects Lean concepts and the concept of optimizing the whole. We need to look across the entire IT spectrum and into the business domain, to figure out how to be more efficient and effective there.

In mainstream agile methods, everyone focuses on what they find interesting: Scrum focuses on project leadership and requirements management; Extreme Programming focuses on technical practices; agile modeling focuses on modeling and documentation; and agile data focuses on database techniques. Those are all good things and important pieces of the puzzle, but none of them address the full puzzle. The full puzzle is how do we deliver a working solution following agile techniques? How do we become more lean and agile at the enterprise level? Right now, we are too narrowly focused.

Read the rest of this great interview here.

July 27, 2011

What project accounting is and why it's important

Project accounting is a critical concept for today's business world, yet most businesspeople do not know their project accounting data. This includes firms that outsource the accounting of others and it results in cost ignorance. Most modern firms have very little understanding of which customers are profitable for them, and which ones are huge losers. R&D projects which should have been cancelled long ago linger on. IT departments languish amid derisive commentary from their peers.

Proper project accounting is one of the many things in life that sounds really easy but, for various reasons – psychological, sociological, political – can often be really hard.

Globalization is just getting started – and it's set to accelerate

The scariest thing about this – for Americans – is that today, there are 1 billion knowledge workers on the internet. Many of them are from countries full of smart, well-educated people who are really tired of poverty.

There are 7 billion people on planet Earth. Today, there are 1 billion knowledge workers. Soon there will be billions more. They'll all be very motivated to figure out what you're up to and how they can do it better, faster and cheaper.

How exactly do you think you're going to stay in business when you don't even understand your costs on a per-project basis? How about your customers? Will they be around and survive the coming tidal wave? In the immortal words of Neil Peart, "Constant change is here to stay." Globalization is accelerating.

It's time to get ready.

We're all bad at project accounting

In my position as CEO of a company that helps people solve these problems, I've seen every kind of company all over the world with various levels of ability trying to attack and fix this issue. Small companies, large ones, consultancies, manufacturers, from South Africa to Sweden to Jordan to New Zealand – nobody understands their costs. Their ability to fix it is not related to the industry they're in or the size of the company. The key differentiator here is the ability to effectively communicate the benefits of the collection of this data to the front line knowledge worker.

Why are we all so bad at project accounting? I've thought about this a great deal and the answer comes down to "future shock" – a term coined in a book of the same name by the sociologist/futurologist Alvin Toffler in 1970. Future shock is a perception of "too much change in too short a period of time"

Our sociological ability to implement effective accounting systems hasn't really caught up with change in the last 50 years.

From Neanderthals to Farmers

Read the rest of this article at The International Community of Project Managers

July 25, 2011

Project budget status is something that should be reviewed regularly, forecasted weekly, and distributed to all key players on the project. If key project personnel aren’t aware of the status of the project financials throughout the engagement, it’s much harder to hold them accountable for what they’re spending on the project. Subsequently, it’s harder to get their help in keeping the project budget on track.

So, given that it’s the customer’s money you’re spending on the project, you’d assume that they always want to know the budget status, right? Well, not always. I’ve had at least three projects in my long history where the customer really didn’t want to have anything to do with budget status and reporting. Whether it was sort of a ‘don’t ask, don’t tell’ situation, or ‘what I don’t know won’t hurt me’, or ‘I don’t want this information in the hands of my team so we’ll keep it quiet’, I’m not exactly certain – each gave differing reasons for refusing ongoing knowledge of the budget status. The most recent example was a multi-million dollar software implementation for a large industrial equipment supplier. The project sponsor – who was mainly a figurehead on the project – wanted the info periodically, but didn’t want anyone else to have it. It was a frustrating situation for me as the project manager – feeling secretive is not a situation that I like to be in with anyone on the customer’s team.

As the project manager, what do you do in these types of situations? What if things start to go poorly and corrective action needs to be taken to salvage the project budget? Then you’re working with a customer who will be surprised or stunned by this information. They won’t likely be your allies in fixing the situation because they haven’t been following it like you have – they’re outsiders up to this point as compared to the project manager. I guess no knowledge = no responsibility…but really?

When I was in this situation, I followed these three steps:

1) As requested, I created two different versions of the status report – one with the budget info that went to my team and one without the budget info that went to the customer team.

2) I made sure that senior management had my status report – including detail on the project financials – each and every week. If it appeared that there was going to be a budget issue, I let them know as proactively and as far in advance as possible. If the customer won’t be my ally on the budget, then the next best thing is the PMO director, the VPs, and/or the CEO of my organization.

3) I closely managed the budget, especially on these three engagements (although it is my practice to do so anyway). I believe this allowed me to take early and successful corrective action. On two of these projects, the budget did start to become ‘unhealthy’ and I initiated discussions with the customer project sponsor to alert them of the fact. It wasn’t the same as openly discussing it as a status item during the weekly customer call, but it was helpful….albeit awkward.

Summary

The takeaway is this: the budget is everyone’s business. Do what you can as the project manager to discuss the project budget up front at kickoff time and let everyone know that you intend to openly manage it and discuss it with the customer on a weekly basis. If you get pushback, then stress its importance while trying to understand the reasoning for the pushback. Educating everyone on tight project financial management may get you over the hump with the customer.

About the Author:
Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

July 22, 2011

Know anyone who falls into one of these categories?? Have a great weekend!

July 20, 2011

Though many businesses use project management software, a common sentiment exists that successful project managers often achieve results in spite of their software tools, rather than because of them. Others believe that project management software is not particularly effective at boosting productivity, citing the large amounts of money spent every year on software that quickly begins to gather dust on some forgotten shelf. In fact, there is well known dispute as to “what exactly is project management software?”

These individuals (whoever they may be) are only partially correct. Project management software, like any tool, must be used effectively by the user. A hammer, regardless of the quality, will not drive a nail by itself. Further, some project management tools are vastly superior to others, either because they are streamlined for a PM job or simply allow for a greater range of processes and data collection. Now let’s be clear, I have always said, “A fool with a tool, is still just a fool.” And on a more positive note, there are extremely successful PMs I know who have managed projects using Microsoft Excel®.

The important thing to remember here is that, for a project manager, something like 80% of the job is communication. For this reason, the primary functionality a project manager looks for in his or her software is seamless integration of data to facilitate rapid feedback and response – or more succinctly, they need timely and accurate information. A manager who can quickly identify if a project is running as scheduled or if an employee is keeping up with necessary and assigned tasks will have the strong advantage of adapting to issues as they arise (and we all know that “Murphy” visits all projects!). Speed and accuracy of information is critical to maintaining this advantage.

Another problem area is when project management software applications go too far in making predictions, suggestions or presenting a myriad of unnecessary options and thereby creating a unique set of problems. Though these suggestions may be valid and the options may provide much more flexibility, it can often result in the project manager becoming at best, confused and at worst, completely sidetracked in the software, even losing sight of the original project requirements. Again, effective project management software will provide the tools for data collection, analysis and distribution. It will not attempt to take over those tasks completely or make “guesses” as to the best course of action where human input is critical. If the software was that good – we would not need to train project managers – right?

Another issue that arises in the use of project management software is the ambiguity of the information presented. For example, even if the software presents the seemingly simple prediction that a project will take 100 hours to complete, difficulties can arise in the interpretation of this information. A novice project manager might be unable to see the other aspects of this task and the issues that might arise. Will these 100 hours be spread over a period of days? Weeks? Longer? And further, how will the human element of the team affect this estimate? Every time an employee takes time off, calls in sick, or falls behind in their assigned task, this estimate will need to be altered. Project management software that is powerful enough to account for delays by tracking these human elements and showing remaining work or effort can greatly increase the effectiveness of a project manager’s resource and schedule management, regardless of skill level.

The lack of software integration is yet another difficulty that can frustrate even the most skilled and efficient project manager. Regardless of the proficiency of individual software applications at completing a given task, failure to integrate with common or existing data from organizational systems can create a nightmare scenario in which the data compiled in a project management program cannot be done in real time. It is not enough for software to allow for the option of integrating with other well-known programs, it must do so well, and with the expectation that the data collected in that program will be used in other capacities.

Project managers that encounter software that allows for the honest, useful, and seamless collection and integration of information will find they have a powerful tool that allows them to accurately predict and produce results with regularity. While software should not be expected to replace effective management or decision making, it can insure that time is being spent in an optimally efficient manner.

And time, after all, is money.

About the Author:
Bruce McGraw is Sr PM, Technologist, and the COO of Cognitive Technologies, a woman-owned consulting firm specializing in project management, collaborative processes, and organizational effectiveness. Bruce has the privilege of overseeing all technology and large-scale projects and the establishment of enterprise program management offices for client organizations. Bruce holds an MS in Technology Management from the University of Maryland's University College and a BS in Business Administration from the University of South Carolina. Bruce is a certified Project Management Professional (PMP) and is an active member of the Project Management Institute. He is also a certified Microsoft Technology Specialist and advises clients on harnessing the new technologies for improving organizational outcomes.

July 18, 2011

Most project managers have experienced an engagement when the customer was a little less than thrilled to be paying a high hourly rate for someone they considered to be somewhat ‘expendable.’ And if it hasn’t happened to you yet, it probably will at some point. Usually, customers are fairly well educated in the process of project management and understand the importance of having a trained and experienced project manager leading a group of skilled resources charged with implementing their solution. They understand that without proper oversight, chaos would likely ensue. But there are still those customers who see the project manager being billed out of a professional services organization at $150/hour or more and wonder what they’re really getting for their money.

The same can be said for internal projects and executive management. If you’re running internal projects in an organization, sooner or later you’re going to run into someone in senior leadership who doesn’t value project management. They may wonder why project management hours need to be hitting their budget for a software development effort or for implementation of a new e-commerce site. They just don’t see the value or the return on investment (ROI). All they see is money being spent.

As project managers, we’re often under the gun to show that we are adding value to the organization, to the project, for executive management, and/or for the customer. How do we do that? What ways can we show added value to the project beyond being a gatekeeper managing the daily tasks of our project team?

Here are a three ways that experienced project managers can add value to their organizations as well as projects they oversee:

Manage scope and implement change orders

Scope management is really the responsibility of everyone on the project – even the customer. Once requirements have been finalized, everyone should be adhering to them and not performing work that falls outside of those requirements. But it happens…through small add-ons, harmless customer requests, and grey area work. Those harmless hours can wreck a project budget if left unchecked.

This is where the experienced project manager can show extreme value. By carefully managing scope as well as deviations to the agreed-upon requirements, unplanned work can be turned into additional revenue for the delivery organization. This revenue could come in the form of change orders or well-documented functionality to the customer for revised requirements. Careful scope management is a win-win situation.

Push for the real solution

Many customers think they know what they need and what it will take to get there. The project manager and team that merely acts on the initial request may end up delivering a final solution that misses the mark in terms of necessary functionality for the customer’s real end users. It is critical that the project manager step in during the planning phase, ask the hard questions and guide his team down the path of figuring out the real issue or need. Often, the original need was merely a symptom of a deeper issue. Finding that real need adds extreme value to the project.

Scale the PM role as needed

As previously mentioned, not all customers value project management. Some see that role as unnecessary. I had one customer tell me at the beginning of the project that he didn’t like me. When my business analyst said, “you don’t even know Brad” the customer answered, “he’s a project manager and I don’t like project managers.’”

I sat down with the customer and found out that his real concern was that he had a limited budget and he was afraid that we were going to spend too much time on my management of the project. That was my cue to be sure I watched what I billed, sent only my developer on site while I managed remotely rather than charging the customer for my travel, and managed the project closely, keeping the customer very informed. I spent as little as I could, but did not give them less service than they needed. They quickly changed their attitude both toward me personally, and project managers in general. I added value (somewhat reversely) to their project by staying in the background when I wasn’t essential at a given moment.

About the Author:
Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

July 15, 2011

“The worldwide communications infrastructure has already started moving gradually and inexorably in the direction of ubiquitous broadband access and transport, an adoption that will completely revamp the meaning of what constitutes a telecommunications service.”

– The 2007 Telecom Industry Review, The Insight Research Corporation

The telecommunications industry is changing rapidly—as is the Internet—and they’re creating a mutual feedback loop. This feedback loop is virtuous if you’re a consumer of such services, but it’s terrifying if you’re a supplier in these industries.

Telecom is changing the Internet, and vice versa. Let’s begin by discussing the Internet’s effect on telecom.

Skype: Freeware Comes to the Telephone

The freeware model for software delivery is a proven method for quickly creating a large user base for your product. In the software space, WinZip and Journyx Timesheet are software products that quickly garnered huge market share due to their zero dollar entry prices. LinkedIn, Yahoo mail and Gmail have taken off in the SaaS space.

Similarly, Skype, an Internet-based PC-to-PC voice communications application, has proven that many users will accept inferior levels of call quality if it is free or extremely low priced. This discovery has irrevocably altered the market and is causing other voice communications firms, including some long established providers, to lower their prices.

Far more important than the commoditization price ‘race to the bottom’ that Skype started is the fact that they convince people to accept the PC as a voice terminal. The company has demonstrated that voice over the Internet, especially when combined with instant messaging and chat technologies, provides some advantages.

There is nothing particularly unique about Skype; any competitor could offer the same service. Its first mover advantage, however, resulted in a large established Skype community, which limits the likelihood of users switching to another service. This means that the race to the bottom will only quicken as new entrants such as Google (which now offers voice-enabled chat on its Gmail service) enter the market with similar free offerings.

A Private Investigator?

Read the rest of this article at SoftwareCEO

July 13, 2011

Estimation can be one of the most difficult parts of a project. Important questions must be asked in order to form the right figures and plans. How long will the project take? How many resources will it consume? Consultants may also ask the following question: What is the appropriate amount to bid on this project? These questions are not easy to answer at the outset when one generally has only a vague idea of what will be required throughout the project.

The good news is that there is a fairly simple way to improve project estimation and, consequently, the bidding process. Most people do not realize that the requirements creation process can lend insight into the length and scope of a project. Let me give you an example of how this method works and then explain how you can implement it within your own company.

The Story

Back in 1992, I was working for a consulting company named The Kernel Group (TKG). During this time, I was put in charge of porting Tivoli’s software from Sun’s Solaris operating system to IBM’s AIX operating system. The project was to be done under a fixed bid, and consequently, we at TKG knew that estimating the effort required to port the code was of paramount importance.

I looked at the code with a coworker of mine, and he came to the conclusion that if Tivoli didn't make the project hard for us in some unspecified way, we could port the million or so lines of code in about a weekend. I told him that he was nuts - that it would take at least a week, maybe even two. We jointly decided that we probably ought to call it three weeks just to be safe. We also decided, rather smugly, not to report our padding of the schedule to evil upper management.

As a result, evil upper management drastically expanded the project bid to $325,000, and my coworker and I thought that this was a ridiculously high price. We believed that we were gouging the customer and that they would never accept it.

Yet they did accept it, and once the project began, we proceeded to discover how truly terrible we as software engineers were at the task of project estimation. To make a long story short, the porting schedule expanded to exceed our original estimate and we consumed not only all of the $325,000, but a whole lot more on top of it.

The Formula

Read the rest of this article at The International Community of Project Managers

July 11, 2011

To certify or not to certify…that seems to be the question. Many job postings for project managers request or even require the project management professional (PMP) certification – the industry standard as offered through the Project Management Institute (PMI). But do organizations need it? Are PMs better for it? Does it guarantee PM or project success? Will our customers care? Is the certification cost to the organization for certifying existing project managers worth the investment? Will the ROI be there or be enough to justify the initial expense?

The certified PMO

A project management office (PMO) full of certified project managers sounds great, right? It sounds like your organization is cutting edge. It sounds like your organization will be bulletproof, ready to take on the project management world and overcome the usual 50+% project failure rate, right?

Not so fast. While a PMO full of PMP certified project managers might mean that everyone speaks the same PM language, it certainly is no guarantee of project success. It may help, or it may mean that you just spent a lot of money putting a ring in the pig’s snout.

Reasons to certify

Certainly there are several reasons to consider certification of your current project managers and requiring it of all incoming project managers. You may be focusing your new business on government contracting and those contracts may require the certification. That’s a very good reason.

You may want a common language and understanding among your project managers. That can be a very good reason if it’s used wisely. Yes, your customers will get a standard brand – returning customers will see the same thing on future projects no matter which project manager is assigned to run the engagement. Think of it like eating at a chain restaurant like Macaroni Grill vs. eating at a one-off place like Joe’s Italian Eatery. One will be consistent no matter what city you’re in. The other, well, you won’t find anything exactly like it again.

A final reason – and this may just be for show or vanity’s sake – is to be able to say you have a PMO full of certified PMs. That is a case-by-case call on what it’s worth to you. You aren’t doing it to acquire business so the monetary aspect may be of little or no consequence. It’s a want, not a need.

Cost of certification

The next thing to consider is the cost of certifying existing employees and hiring only PMPs going forward. This is a consideration in every case except something like the government contracting scenario where it’s absolutely necessary no matter the cost because it’s required for getting new business.

First, there’s the cost of testing. Currently the fee is $555 for non-members of PMI and $405 for PMI members. And if you’re going to require certification, you should probably buy memberships for the entire group. Let’s say you’ve got 15 PMs in your PMO. A one-year PMI membership is $129. That’s $1,935 in memberships. The tests will cost another $6,075 for a total of $8,010 if everyone passes, and then a recurring $1,935 each year to renew PMI memberships. Over the course of say, five years, that’s a total investment of $15,750, assuming your PMO does not grow in size during that five-year period.

New hires are another consideration. Since the requirements to take the exam and actually pass the test are not that high – essentially two solid years of PM experience and a 61% passing grade on the exam – it doesn’t mean you’re forced to hire the most experienced personnel. Given that, salaries aren’t likely to be any higher unless you’re looking for lots of experience AND a PMP certification.

Summary

The final decision to require certification is obviously up to each organization and may be based on business need or just pure want. The cost is not exorbitant to the corporation, but it is definitely a long-term investment that needs to be considered. However, since the requirements are low for taking and passing the exam, PMO directors and company executives must not be blind to the fact that PMP certification doesn’t guarantee PM or project success. Unless there is a true business case for the PMP certification need, experience and proven past PM success should always be the greater deciding factor when building a successful project management infrastructure.

About the Author:
Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

July 8, 2011

Enjoy your weekend!!

Pages