Copyright © American Eagle Group
Copyright © American Eagle Group
Copyright © American Eagle Group
For the past several months, our team of researchers have dug through many articles, discussed what they have learned and explored their own desires concerning leadership as being millennials. Here are the five points we have learned so far.
Take our 5 minute survey here.
Millennials understand respect for current leaders is important. They also want to be respected by the leadership. Respect is always a two-way street. By showing disrespect from either side, the other party is immediately alienated and the relationship breaks down. As a result of the damaged relationship, the leader has little to no influence.
Millennials need to be respected for what they know. Because they grew up in an age of hyper-technology, they think differently than the older generation and as a result, come at problems in dissimilar manners. These manners may bring about challenging questions by which the leader should not be offended or become defensive, but consider their viewpoint because the questions may lead to answers. Millennials don’t expect all their questions to be correct or in the proper direction, but at least being heard and considered goes a long way in showing respect. And this is not too dissimilar to any generation’s desire – to be heard and taken under consideration.
Millennials are eager to do the work assigned to them. They are eager to perform and complete the tasks at hand. They are eager to participate. After all, in majority of cases, they participated in team sports and competitions. They know the feeling of winning and losing.
When leaders show appreciation for the work being done by millennial workers, it provides the workers with a sense of pride and accomplishment. They want to know they are part of the team and helping to move the project forward. Again, which generation does not want to feel appreciated for their work?
Millennials want to know what they are working on is making an impact, making a difference for the company. They understand there are menial tasks that must be performed, but they want to feel their efforts contribute to the success of the company.
We have all worked those situations which were boring and in the end, had no impact or significance. At the time, it might have appeared to be important, but in the end, the project was canceled or abandoned and the result useless. Those situation are understandable, but if day-to-day work doesn’t amount to anything, then we all become demoralized.
Leaders need to provide the vision which leads to meaningful and productive activity.
Leaders need to adapt to the situation at hand and to the people involved. One-way does not fit all. It never did and never will. Different situations require different approaches. For example, in emergency situations, the leader may become more dictatorial and demand certain actions. The followers will most likely follow. But under normal conditions, if the leader continues in the dictator mode, the followers will resent the heavy-handed approach and eventually rebel.
As the team composition changes or the environment, market factors, upper management, etc. varies, the leader must adapt accordingly. Again, this concept of adaptability is just good leadership anyway. There is nothing new here concerning the millennials. It seems they desire good leadership models.
Hmm, maybe it is not the millennials we should focus on, but those people who currently hold leadership positions who don’t really understand leadership!
In many cases, millennials have put in long hours of study to learn their skills and have the loans to prove it. In other cases, in addition to their education, they have spent years in the workforce and have experience harden by the reality of mistakes, corrections and leading by other employees and life in general. They want to be able to exercise that knowledge. They want to be trusted to do the job. Leaders need to delegate authority and responsibility to these workers and trust the job will get done.
Some leaders have been hesitant to delegate authority and responsibility. This attitude makes no sense. When they were younger, they were eager to prove themselves. Their leaders and management gave them opportunities to prove themselves, otherwise, they would not be in the position they are in today. Leaders need to trust the millennial will get the work done. Delegate the authority and responsibility to do so.
When we sit back and look at the situation, the millennials are no different than many of us when we were their age. We remember applying for jobs to start our careers and the job requirements stated experience was necessary. We often wondered how do we gain experience if experience is needed to get the job in the first place. Eventually, someone took the risk and hired us. We grew into the position.
As we researchers discussed the articles we read and our desires concerning leadership traits, we came to the realization that our leaders probably had the same concerns about us when we started our careers as current leaders have about millennials today. Are they capable? Can they get the job done? What if they make mistakes? How can we hand off our positions and know it will be successful? The fact is, just as we learned through our successes and failures, the next generation will do the same.
The difference may be in the fact we, the current leadership, have raised the millennial generation. One of the things we taught them was to not cow-tail to the whims of poor leadership. And maybe, just maybe, we are not as confident in our ability as leaders to withstand the very trait we taught our millennials. We will cover that in future articles.
Copyright © American Eagle Group
We need to ask the question, “WHY do we need project management?” Moree specifically, “Why do we need to formalize it?” We get the job done, don’t we? Nights, weekends, overtime, “the beatings will continue until the moral improves” as Blackbeard the pirate was fond of saying. We do what it takes. So, why formalize project management?
Let’s be real. We seem to get projects finished. It may not always be pretty. We may burn out a few people. And we may end up over-budget and behind schedule, but we do get them done. How can using processes help us?
By defining a process, we take the best of what we have done and do it again. If we never document what we have done, we have a hard time repeating it. We have a hard time transferring the job to someone else. If the person who knows the method to accomplish some task gets sick, leaves the company or worse, goes on vacation, how will we finish the work?
Processes make what we do:
For those in the know, this cycle is simply a restatement of Walter Shewart and Peter Demings’ Plan-Do-Check-Act quality improvement methodology.
Another benefit of documented processes is “institutional knowledge.” We transfer the knowledge of the best practices to others on our team. They don’t have to learn from scratch or from observing others. The steps are defined and refined to improve our productivity and effectiveness.
Documenting processes does not need to be complicated. For example, following the nine steps while building your project plan as defined in this manual saves you time. Yes, there is a learning curve and lower productivity while you learn the process, but the end result is repeatable actions saving time and delivering predictable results.
For example, after a while, people learn the shortest or fastest path to get to work (well, more likely, to get home from work). They use the same path over and over because they know it works. The first time they took the route, they probably mapped it out using Google Maps or some other service, GPS, etc. Once they became familiar with the area, they may have learned shortcuts not originally given by the earlier process. They actively decide to take the shortcut. Had they not had the original route, they wouldn’t have known the shortcut was truly shorter. By tracking the original path, they knew when they deviated from it and how to improve it.
Going back to our drive-home route example, we learn by leaving the office at 5:00 pm, we should be at the red light on 45th and Main Streets by 5:25 pm. If we are there earlier, we’re doing great. If we don’t reach the intersection until 5:45 pm, we know we are running behind schedule.
Those measurements let us know how we are progressing and if the process is still working. If we discover a slightly different route which chops fifteen minutes out of the schedule and yet delivers the same results (quality, performance, outcome), we modify our process – the route we drive. By knowing the amount of time prior to the improvement and the new time after the improvement, we have a comparison for future performance measurement.
If the time begins to increase back to the original – others find the same route and it becomes jammed – we begin to look for improvements again. The measurements let us know how we are performing.
The key, therefore, is the very first step: eliminate the Wild-West approach of “just gitt’er dun,” by documenting the processes, tracking, measuring and improving.
1. Implementing processes takes time, lowers productivity and adds bureaucracy and red-tape.
To document what we have been doing and creating processes is a lot of work – True. They slow people down – True. They create more paperwork – True. Processes hold people accountable and we know the responsible person when something goes wrong – True.
Well, all those are true and more – at least initially. There is a learning curve to anything new. Fact is, people are following a process now, whether it is documented or not. But in many cases, only they know the process. Therefore, if the person has to be replaced, the substituted person struggles and typically can’t keep up. Overall, the work slows down.
By defining the process, others learn or at least have some reference information to accomplish the tasks and in the proper sequence.
Additionally, we know who is responsible for doing what. We are not here to point fingers, but more to determine how to fix problems. Is it training? Does the person have the wrong authority? Are they physically capable or incapable of doing the job? We can pinpoint the problem and apply a solution.
2. People hate being told what to do and don’t like change. They want the liberty to do it their own way. If the truth be told, processes are more liberating than confining. Rather than fretting over the next step, their decision-making capacity is spent on improvements, not reinventing the wheel. By making them a part of the process development or improvement, they become co-owners and more involved raising the quality of their work.
Process has its benefits and detractions. Once it becomes part of the daily routine, we simply do it and stop noticing it, just as we stroll the same route to get a cup of coffee. Any change to the path causes consternation to many; a loss of productivity until the change becomes part of the regular course of business. By having a formal process, we can examine it for inefficiencies and fix them because they always exist.
Project management is not a singular process, but a complex interplay of processes and methods across multiple divisions and disciplines within the organization. Without process, without formalization, we cannot keep the lines of communications, work and results from becoming entangled. Following the RTMI discussed in this article, companies can reap the benefits of formal project management methodology while minimizing its disadvantages.
Copyright © 2014, David A. Zimmer, PMP All Rights Reserved
Gathering requirements for a project is critically important to the overall project success. Without proper requirements, detailed so they are attainable, a project manager’s ability to achieve project completion or stakeholders’ satisfaction is greatly diminished. Basically, he is shooting in the dark hoping he’ll hit something akin to the thoughts and expectations of the influential powers. For many organizations, requirements gathering is not a process but rather a race to implementation.
A company hired us to help them conduct proper technology selection for a strategic business application. At our first meeting with the client, we asked if requirements had been gathered concerning the new platform. They proudly produced a half-page, bulleted list of items the new system was to provide. We politely asked if that was it. No details. No lists of user needs, business tie-ins, strategic propositions, or customer service thoughts. Ten bullet items of “wants.”
Fortunately, and in anticipation since we had seen this before, we produced a document listing requirements and their descriptions we had accumulated over the years working with other clients. The ‘thud’ on the table startled the client a bit, but he was very excited we had something real from which to work, and more so, because he didn’t have to create the same list and description – the work was done!
The Project Management Body of Knowledge (PMBOK® Guide ver. 4) states in Process 5.1 – Collect Requirements, “Collect Requirements is the process of defining and documenting stakeholders’ needs to meet the project objectives. The project’s success is directly influenced by the care taken in capturing and managing project and product requirements.” It goes on to describe the inputs, tools and techniques, and outputs of the process. Fundamentally, the discussion is accurate, but it leaves out the perspective of each stakeholder. While implicitly suggesting the six perspectives outlined in this article, explicitly and proactively viewing each perspective provides clearer and more complete requirements for any project.
We turned to the Business Analysis Body of Knowledge (BABOK® Guide ver. 1.6) to see if they included discussion of the six perspectives. Again, they discussed the tools and techniques with a mention of various stakeholders. Once again, we want to be more explicitly clear of the viewpoints.
The IT Cube is a conceptual method of ensuring all aspects of a project, technology selection, or decision is adequately considered.
Imagine a project as a sphere. Place that sphere inside a six equally-sided box or 3D cube. Each side is transparent so the sphere is easily seen. As you view the sphere through each of the clear sides, you see a different aspect of the ball. From one perspective, the ball may appear blue. From another, peach. From a third, dimpled and so on until you have looked through all six panels. Each view portrays a different “idea” of the sphere.
The same holds true as you focus on project requirements, product definition, service features, etc. By explicitly considering each angle of the project, different requirements emerge. Some may be in direct conflict or compliment requirements from another view. Unless studied in this manner, those requirement clashes may not emerge.
Six perspectives for any project exist. They are:
1. The “Technician”
2. “Technical” Management
3. Business Management and Executives
4. The User or Customer
5. Analysts and Pundits
Each has a unique view of the project and a vested interest in its outcome, with a possible exception of the Analysts and Pundits, although, their opinions can influence decisions.
Let’s define each and understand their needs.
Our background is IT and therefore we think in terms of business application software and hardware infrastructure. Not all projects are IT focused, consequently, we want to broaden our discussion here to be more generic. The term “technician” has more to do with the people implementing the project. For example, in construction projects, the technician would be the laborer whose skills build. In marketing projects, the marketing person developing plans becomes the technician. The chemist and research scientist would be the technicians in pharmaceutical developments. And so forth.
The questions a technician might ask concerning the project and therefore, their requirements will be more of a technical nature. For example, they might ask
•“How will the new system impact the current infrastructure?”
•“Is this an additional item to our list of services to the organization?”
•“Do I have to learn new information or will my current knowledge be sufficient?”
•“If new knowledge is needed, will I be trained?”
•“Are we doing away with something else?”
As shown, the questions concern the day-to-day operations. Support questions might come to mind once the new “technology” is selected, especially if the technician will be supporting others. In the case of the research scientist, it might be “what support will I get” and so forth.
Therefore, gathering requirements from this group of people is important because they will be the ones implementing the solution and possibly supporting it. As a result, day-to-day operations success after implementation depends on the buy-in and commitment of this group of individuals.
“Technical” management concerns are different. This group of people is the managers of the “technicians.” The management must answer to two groups: Business Management and Technicians. Essentially, their requirements include meeting the business ROI, TCO and SLAs while at the same time, supporting the needs of the technicians to operate the technology efficiently.
Their questions may be:
•“How will this technology meet the organizational ROI and TCO requirements?”
•“Will the new system help me meet the SLAs better or more easily?”
•“Will it make the technicians’ work easier so we can provide other services?”
•“Are there other methods of meeting the needs expressed or do we already have systems in place so we don’t need to add another?”
•“Will this meet the business initiatives and align with the strategic plan?”
The questions follow a more business line of thinking, but still with a technical orientation.
Business Management and Executives look at the profit and loss propositions of any new implementation. Their goal is to meet their goals as stated in the strategic plan, along with their own initiatives. Each project should move them further along those plans.
This group’s questions might be:
•“How will this technology align with the strategic plan?”
•“I don’t care about the technology so much. I’m more concerned with it meeting my goals, objectives and initiatives.”
•“How will this project move me further along my initiatives?”
•“How will this implementation make us more revenue or profit?”
•“What is the cost?”
•“What is the priority of the project compared to other needs?”
•“Does the return outweigh the cost or the cultural impact we will incur?”
Notice the questions center around financials and investments of money with overtones of impact on the company environment.
The users or customers employ the project’s outcome. Their needs determine the usefulness of the project’s result and its use. Whether the project results in a building, a new medicine, a software package to automate tasks, or whatever, the acid test of any successful project is its users’ acceptance. Involving the customer during requirements gathering is essential in the final analysis.
Customers or users may ask:
•“Why do we need something new or better?”
•“How will this benefit me?”
•“Will this help me do my work better, faster, or with less people?”
•“Does it eliminate the frustration I am feeling with the current method or system?”
•“I need this item or this feature. Will the new system do that for me?”
The questions center on their particular set of tasks or duties. They are more tactical in nature, getting down to the day-to-day operations of the business.
Industry Analysts provide valuable information from a different perspective. They may rate the technology vendor’s stability and longevity – an important aspect for large investments or long term usage. They review the feature set against other offerings of similar ilk and point up the highlights and lowlights of the offering. They present ideas and opinions based on customer surveys and questionnaires. In many cases, they present a more objective viewpoint.
This group of people might wonder:
•“How financially stable is this vendor?”
•“What is their customer support structure? Do they support both large and small customers?”
•“What is the vendor’s current customer base?”
•“How does their product or service feature set stack up to the competition’s?”
•“Do they support just a niche market or do they serve a more general audience?”
•“Do they meet the expressed needs of customers according to our surveys and research?”
•“What advice can I tell my customers about this product or service? What opinions will they find valuable?”
Vendors are the ones producing the product or service you want to buy. In many cases, the product or service you are considering will meet some, but not all of your needs or desires. Vendors want to know what your requirements are so they can help you understand which ones they support and how closely. For the ones they don’t support, they will find creative ways to support them.
Vendors will ask:
•“What is your ultimate end result you want to achieve so we can show you how we can help you get there?”
•Why do you think you need that feature or function?”
•“In order for us to be able to support your need, you need to do X, Y and Z. Is that OK?”
•“If this project is successful, what quantity of products or services will you purchase?”
•“How can we aid in making your project successful?”
The vendor is looking to sell products and services. They might place requirements on your project to make it better.
While all the perspective descriptions may not be directly valid for every project, the different angles should be addressed. For example, an internal project that doesn’t use outside vendor offerings still has internal vendors and customers. Those perspectives must be considered and documented. If no requirements come from a particular perspective, then we should explicitly note that fact.
IT Cube is a conceptual model to follow to ensure all stakeholder needs are considered. Missing one side of the cube will leave an opening dumping the project’s success onto the floor.
We invite you to comment on this article. Does the concept make sense to you? Are there additional sides we should consider? Is it a useful model for eliciting requirements and practical enough to ensure full consideration of stakeholders’ needs? Let us know what you think by leaving a comment.
IT Cube is a trademark of American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective trademark holder.
Copyright © 2009, David A. Zimmer, PMP All Rights Reserved
Recently, I spoke with my old partner of the Unified-View, Art Rosenberg, about the recent press release by Orange concerning UC Hosting services. In particular, they announced their support for ITIL (IT Infrastructure Libraries) practices in order to best support their customers.
Since I last worked with Art in 2002 or 2003 timeframe, I have diverted into another path of consulting: project management and IT service management. These two areas answer many of the questions Art and I raised several years ago in search of the migration strategies for IT managers as they planned their UC implementations.
We wanted to know what methodology people would follow to plan UC projects while at the same time maintaining current technology so the business did not grind to a halt. We needed to know how individual users would determine which features and functions would best benefit them in doing their jobs better. We knew one size does not fit all. How can the telcom/IT managers align with both business initiatives and end user needs or would they simply cobble something together and dub it UC? Once in place, how would UC continue to evolve seeing it has so many moving parts with new technology and releases coming out rapidly while supporting SLAs and stability requirements?
After twenty-five years of managing small to large technology projects, I learned there was formal training needed in project management. While for many, formal education was an obvious opportunity, I always felt, as many do, project management is simply learned by being around other people who managed projects and mimic them. I learned within the first session of my education, I was wrong. Now, I am not only formally trained, but I am certified as a Project Management Professional.
Since 2004, I have trained thousands in the art and science of project management with great success in turning projects within companies around simply by instituting a few simple processes.
Similarly, I never realized formal industry standards existed for day-to-day operations of IT systems until I ran into the ITIL framework. I simply thought fixing fires and trying to predict future flare-ups was the norm. (Sadly, it is, but that can change with proper methodologies.) I am certified in ITIL version 2 and ITIL version 3 fundamentals.
In speaking with Art about UC implementation, I realized a broader audience would benefit from our discussion. Because of the nature of UC, its fluidity, variance of definition by company and user-base, and rapid advancements, project management and ITIL concepts and processes are key to successful deployment and upkeep of the system.
The PMO or Project Management Office is the focal point for project management governance and oversight. It establishes the guidelines and standards to be followed. Typically the PMO focus is on projects only. They have not been concerned with day-to-day operations.
For many companies, the PMO originated from the need to manage IT projects more successfully. Industry studies report close to 75% of IT projects fail. The PMO was implemented to increase the success rate. For those companies who have gone the certification route through the Project Management Institute (www.pmi.org) and trained their project managers, studies report a 70% success rate instead.
The success of the PMO governance and guidance of projects has lead many to believe that daily operations would benefit from similar oversight. As a result, the PMO has to morph into an organization supporting two industry standards. Traditional project management methodology does not support operations.
Additionally, the experience set of the two domains are quite different. For example, projects are a specific scope of work defined by begin and end dates, and the resulting product or service transitions into operations.
Operations, however, is ongoing, so they have no end dates but must smoothly transition new functionality and supporting infrastructure without any impact to the business.
Here is a bullet list of topics to be covered in this series of articles:
•An overview of PMO functionality,
•Determining the need for UC (It’s not just IT management!),
•Proper project management methodologies,
•ITIL practices as they pertain to UC – both version 2 and version 3,
•Comparison of Project Management and ITIL methodologies,
•UC planning and implementation strategies,
•UC lifecycle – evolutionary definition, evaluation, implementation and support of business needs as experience dictates and business drivers change (mobility, device upgrades, new technology, regulations and legislations compliance, competitive needs, social impacts, etc.),
•Ongoing enhancements and support of the UC infrastructure,
I will reference practical experience from my past, but I would like to showcase others’ experiences also. Tell me how you handle your daily operations, any experience you’ve had with ITIL or project management practices, sticky points you’d like an opinion on, etc. You can reach me at email@example.com or www.ameagle.com.
Copyright © 2008, David A. Zimmer, PMP All Rights Reserved
I recently read an article appearing in CIO Magazine titled “Common Project Management Metrics Doom IT Departments to Failure” where the subtitled mentioned a report by Forrester Research stated the metrics used to measure IT project success influences the perceptions of failure. It goes on to say that we need to change to increase the perception of success instead.
We’ve all heard the adage “perception is fact” implying perception is not fact, it only has the allusion to be factual. I don’t know if it is my sense of humor, but the statement of “increase the perception of success” was strangely funny. Did it mean the project was actually a failure but we make it appear successful? Does it harken to another well-tread cliché, “In project management, we simply redefine the parameters and declare victory. That’s how we have successful projects!”
The article further details four things the PMO can do to help increase the perception of success. While I agree with them:
I believe they miss the fundamental basics of the problems – the root causes.
According to the Standish Group, IT projects have only a 29% chance of succeeding. You would think with the advance in technology, the development of quality processes and increase of understanding humans; we’d have a better shot of being successful. In 2003, the Standish Group estimated we spent $382 billion on IT projects in the US alone. They further stated $82 billion was an outright waste. Using the 71% failure rate, we spent $271 billion on failed projects. Maybe that’s why we need to increase the perception of success – so we can balance the books!
Based upon my years of managing IT projects (I’ll admit, not all were successes, perceived or otherwise) and experience training more than a thousand people in the art of project management, I believe the following are the root causes for IT project failures.
In my training seminars, I ask how many people actually chose project management as a career. I have had only three people raise their hands. Usually, we are selected because we are doing well in our “real” jobs and seemed to be organized getting things done. One day, as we arrive in our office, twang, we are dubbed project managers. No training.
Then I ask how many have any sort of formal training in managing projects. Regardless of the industry, the percentage is basically the same, only 20% have had any form of training. I reduce the definition of training to the ridiculous of a one hour discussion and very few additional hands go up. Only 5% have more than a day and 1% go on to be certified through Project Management Institutes’ Project Management Professional certification.
It is not we aren’t intelligent and can’t learn the ropes, but usually we learn by observing others who have gone before us. They learned the same way – by observing others. As a result, improper methods are learned and used rather than industry accepted practices. We just gitter dun – whatever it takes, nights, weekends, extra shifts, Herculean efforts – we gitter dun.
As a result, we don’t put the proper measures in place to give the information business people need. Worse, we really don’t know where we stand in our own projects. We can’t repeat our successes because we don’t know what we did to be successful. We don’t always learn from our mistakes so we are doomed to repeating them. And finally, many projects we considered successful really weren’t causing us to repeat bad habits because we believe they are good practices.
Through training, we learn proper techniques, why certain processes should be followed and the tools we need as project managers. To contrast untrained project managers with a failure rate of 71%, studies have shown using trained and certified project managers – PMPs specifically – succeed close to 75% of the time.
In the CIO magazine article, someone placed a comment contrasting construction project management with IT project management. He stated IT methods are primitive to constructions processes. I agree totally.
First, construction follows a methodical, time-proven method. They work from blueprints with every detail shown. They research the site and understand what lies hidden before digging. They understand the necessary inventory of materials and labors in advance of the start date. But most importantly, they have a change process.
Once the deal is signed, any changes to the agreement require a change order with signatures. The change order details the impacts to schedule, increase to budget, amendment to the project scope, etc. Each party must sign before the change occurs, otherwise, the original plan holds. No changes are made unless the boss says so.
In IT, we take a different tack. Again, from my survey of many attendees, only three or four people stated their company had a formal change form and process. Worse, they reported changes to the project can come from any where through any channel to any member of the project team. Since many things are considered “easy,” the impact to the rest of the project and beyond is never considered. If a change is formally documented, no one dares sign it. Accountability is forbidden.
As a result, what is defined to be the project is not really the project. As time passes, changes are requested but not tracked. The project morphs and twists into something other than the original definition. As a result, the original project may have been successful using the traditional metrics, but no one can prove it because no clear definition of the project exists.
Additionally, changes come through various portals. There might be a formal request sent from the CIO to the IT project manager. Another request comes from the sales manager tapping someone on the shoulder in the hallway. A third and most insidious is the IT staffer who “sees something needs to be done, and does it” without tracking the impact to the overall project.
Solution for such a situation is two-fold: a well defined and followed project scope and a formal method for requesting changes.
A successful project must meet the expectations of the stakeholders. Even if it comes in on budget and on time, if it doesn’t meet their expectations, it failed. Unfortunately, we don’t document the expectations. We document the technical requirements, the inventory list of hardware and software needed, select the team of implementers, etc., but we don’t seem to jot down the expectations.
If we don’t document the expectations, how do we know when we are finished? If the expectations are met, we would have success by definition, correct?
Of course, the stakeholders don’t always reveal their expectations for us to conveniently document. In fact, their expectations change over the course of the project. Even if we met the original expectations, we still fail because we didn’t meet the current list of desires.
As a result, project managers must spend a good deal of time understanding the stakeholders’ motivations, desires, intents, and rationale for the project. Periodically, he must check in with the stakeholders to verify current understanding of their needs and make adjustments accordingly.
I don’t feel it is right to simply change the perception of IT project success. To me, that’s cheating and we don’t solve the real issues. We need to change how we “do” IT project management to be successful. Proper training is key number one. I, like many, managed many projects before I was formally trained. Boy did I learn about my bad habits and improper ways of managing projects. As I instruct others these days from my lessons learned, I see the same transformation in them.
IT doesn’t have to suffer the fate of poorly run, failing projects. Solving the root causes for those problems would go a long way in better return on investments, fewer dollars wasted, and happier IT people. Once these are fixed, we can begin to work on the list from the CIO article.
Copyright © 2008, David A. Zimmer, PMP All Rights Reserved
Utility Services is a governance model of ensuring all solutions implemented within an IT organization meet the traditional criteria of customer sign-off requirements, solution design and testing, and release into the environment. It establishes and enforces necessary customer communication checkpoints via a series of documentable and repeatable processes and procedures. It ensures IT goals align with business needs and initiatives through a consolidated resource management interface to manage work-loads and enable resource forecasting. And finally, it streamlines standard requests by automating approvals, traceable milestones, requester communication and hand-offs as appropriate.
The big question still remains. Why implement Utility Services? You already seem to be getting the job done. Sure, your people are overworked and under-appreciated, but they still show up for work each day, don’t they? Why rock the boat, change the way of doing things and suffer through the cultural shock of more efficient operations?
For those companies where we helped them implement Utility Services, here is what they report:
Fulfilling business requests takes up much of IT’s daily time. Inefficient methodologies erode the very infrastructure and people required to keep the business going. Untraceable changes and updates introduce instability into an already overly complex and vital system to the business. Personal agendas and priorities drive the changes without considering the benefit or detriment to the business. IT staff, desiring to do a good job and meet the needs, work at full speed but seem to fall short at the end of the day.
Utility Services takes the inefficiencies, the uncertainties, the liabilities and the insecurities out of IT Request Fulfillment. By funneling requests through an automated and organized process, duplication of effort is eliminated, overspending on materials is slashed, workloads can be adjusted to align with business needs, personal agendas can be removed and priorities are established to truly meet the business’ highest priorities for the greatest gain.
We have seen companies transformed saving millions of dollar annually on purchases alone. IT efficiency increased dramatically and the stability of the infrastructure reached desired service levels without significantly increasing costs. The implementation and definition of Utility Services takes a chaotic methodology, structures it and drives it for the maximum utility to the business.
Copyrighted by American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective copyright holders.
When I was younger, I ate alphabet soup. I stirred the broth and watched the letters as they swirled around. Many times, simple words rose to the top. As I learned to read, I would exclaim the new found word. Little did I know that as I matured, letters would continue to swirl and new found words and acronyms would continue to form. The IT broth has been stirred. While not necessarily new, PMO, CobiT and ITIL seem to be rising to the top of the bowl in the IT industry.
Fig. 1: Three Avenues To Better IT Infrastructure Services
We have three, and more, efforts trying to solve the IT dilemma – providing quality services in an ever changing environment while aligning with business requirements and drivers. We need to understand these three – PMO, ITIL and CobiT, and how they integrate to provide the best IT Infrastructure services. The questions we need to answer are
This article introduces a series of articles describing the various components and how they integrate forming a comprehensive governance of IT within your organization. Each component is not mutually exclusive of the others; in fact, they are greatly complementary. The overlap provides us the opportunities to better understand IT relationship to and support of the business requirements for your organization. IT is no longer a cost center draining the organization of precious resources, but becomes a strategic weapon supporting the business in its efforts to out maneuver the competition and branch into new markets. Although we have often heard that statement, the use of CobiT and ITIL provides the mean to make it true.
By necessity, we will only introduce the various topics at a very high level, saving the details for the later articles in the series. We have purposely simplified these complex areas in order to introduce them, but we will add the details later. So, if you are an expert in these areas already, bare with us as we bring the rest of the readership up-to-speed. We discuss three elephants of understanding, so we need to only chew what we are able. If you are a neophyte, welcome and fasten your seatbelts – turbulence ahead.
Let’s start our journey by understanding briefly the five components within the system as shown in Figure 2: Business requirements and drivers, IT/IS Systems, Services and Infrastructure, Project Management Office (PMO), Information Technologies Infrastructure Library (ITIL) and Control OBjectives for Information and related Technologies (CobiT).
Fig. 2: PMO, CobiT, ITIL Integration
The business requirements and drivers determine the direction of the organization. The IT infrastructure is expected to support that direction. In many cases, the business requirements are not adequately documented or communicated to the IT personnel to gain such support. Additionally, the requirements speak a different language than the IT department.
The CIO and IT Management translate between the business needs and the IT infrastructure reality. Without a standard approach to such translation, it may not be as accurate as needed. The results: a mismatch between the infrastructure and the needs, festering frustrations and creating divisions. Unfortunately, this incomplete or inconsistent translation is not seen until well into the process of implementation or even during actual use. The cost of fixing such a dilemma becomes exorbitant. Industry studies show that over 66% of IT-based projects fail!
By using a standard approach with appropriate metrics and life-cycle planning, we begin to mate the business requirements and IT infrastructure realities. Within the standard approach, we add auditing ability to give us the checks-n-balances needed to assure we obtain the proper return on investments.
The IT infrastructure and systems support the ongoing business. It meets the needs for the users’ day-to-day operations and any new development work. The infrastructure includes desktop and server machines, networks, storage, and software used to meet business demands. Software includes the general purpose programs such as word processors, spreadsheet and presentation software, email, etc. It also includes specialty software such as CAD/CAM, publishing, accounting, CRM, ERP, etc.
The infrastructure becomes a reality based upon the business requirements understanding and established through some type of project procedure. The goal is to evolve the infrastructure as the business requirements change and mold to market conditions. One problem that exists is the rapidity of requirements changing versus the speed of evolution of the IT infrastructure. Add to that disparity the non-standard method of translating business requirements into infrastructure reality and the lack of auditable metrics, we begin to see the quandary we possess.
The Project Management Office is a virtual organization within your organization that is populated with people who manage projects. Projects translate business requirements into IT infrastructure realities to be used for the business evolution. The PMO dispatches a project manager to manage a project which implements the desired solution. In a perfect world, the end result would match the business requirements. Using best practices and standard procedures, the project manager guides the project to the desired results with full acceptance from the users and receives standing ovations and a hero’s welcome. Right?!
The Project Management industry has done an admirable job in defining the process from requirements to reality, but by their very definition, their responsibility ends at project completion. A project is a temporary endeavor to produce a unique product or service (PMBOK). The definition defines a beginning and end to a project. Once the project is complete, there is no ongoing feedback loop to evaluate the results of the project. The project manager’s responsibility is complete.
Ongoing monitoring of the project’s results must occur in light of the business requirements that drove the project in the first place. Are the results still in line with the business requirements? Did the requirements change? Did the market factors that defined the requirements change? If so, should we change the infrastructure? What is the process? How do we determine the financial impact? These and many more questions start flooding one’s mind.
Enter ITIL – Information Technologies Infrastructure Library. ITIL is a collection of best practices that help move business requirements through the project stage, into the reality or implementation stage and provides the life-cycle feedback necessary to keep the infrastructure aligned with those requirements. Driven from the technical community to better understand requirements from its primary customers – the business user and management, ITIL standardizes the language so business requirements translate into technical terms properly, or at least, consistently.
ITIL is not a “how’s to” guide to better IT Service Management. It is a framework of practices to measure, validate, and report against the business needs and requirements. It shows how the IT infrastructure works together to meet the business needs. In other words, it lets the business dictate the implementation of IT services and infrastructure rather than letting the latest IT advance push the business to its adoption. More importantly, it uses a common vocabulary to promote synergy between the business drivers and IT implementations. It becomes a collection of documents outlining the process from requirements to implementation and back to requirements.
Two versions dominate the ITIL landscape today: version 2 and version 3. Version 3 has been ratified and is being introduced to organizations now. Version 3 is an evolution of version 2.
Version 2 focused on process development. It defines the necessary best practices to create IT realities from business requirements. Using common vocabulary, business users could articulate their needs at the beginning of the implementation process and then measure the outcomes once the IT infrastructure was deployed. Version 2 looked at specific discrete areas and disciplines, so it was seen as “silo focused.” Version 3 takes those best practices, now that they are defined in Version 2, and applies them in a holistic view of the organization. It provides a feedback loop using the common vocabulary and best practices into the requirements process giving us a tangible, business life-cycle from requirements identification and definition to implementation to acceptance and back into the requirements phase again. It provides the step-wise refinement necessary in IT evolution for constant business support.
In Figure 2 above, we can see that ITIL underlies the first three components discussed: Business Requirements, PMO and IT Infrastructure and Services (the blue ellipse). As you can see from the life-cycle arrows, it starts before a project initiates, continues during the PMO’s involvement and lasts long after the project manager has gone home.
The PMO uses ITIL’s framework to ensure proper monitoring and adjustments necessary to align the project results with the business requirements. The life-cycle arrows show the feedback loop going back into the PMO resulting in infrastructure changes and so on. The PMO does not obviate the need for ITIL, nor does ITIL displace the PMO. The PMO provides the methodology for a systematic step formation for managing projects. ITIL provides the components projects must supply for future monitoring of the projects’ outcomes.
Control OBjectives for Information and related Technologies (CobiT) comes from the audit industry. From the fallout of Enron and other notable large organizations’ scandals, we see the rise of legislation and regulations requiring accountability in all facets of companies. Because of regulations such as Sarbanes-Oxley (SOX), every aspect of business comes under the microscope of the auditors. IT is no exception. CobiT is a framework of good practices that places audit points into IT services so that we can determine financial accountability. It goes beyond the financial aspect and compliments the tenets espoused in ITIL. So while ITIL documents the life-cycle of IT infrastructure and services, CobiT keeps our attention to the audit criteria and gives us the checkpoints needed to assure compliance. CobiT defines 34 audit points that span ITIL’s domain – before project initiation and lasts long after the project is over. It provides a life-cycle as ITIL does, but it focuses more on a direct correlation between business requirements and IT infrastructure realities financially. It underpins the PMO with audit points.
PMO, ITIL, CobiT – three acronyms formed by the swirling IT broth. Each focuses on different aspects of the IT business. Each hope to convert business requirements into IT infrastructure that support the business needs. Each provides a different perspective on the road from business requirements to IT infrastructure realities. But they are not mutually exclusive. In fact, we see each underpinning the others for a mutual benefit. The PMO uses ITIL and CobiT so the project results enter a life-cycle that is accountable and tractable. ITIL uses the PMO to establish the life-cycle necessary for feedback and monitoring of the infrastructure to the benefit of the organization. CobiT puts into place the audit points keeping our business on course and out of hot water. It uses ITIL to document the audit process and the PMO to implement the audit points. Each leverages the strength of the other.
This article is just a cursory introduction to the deeper aspects of each component. In subsequent articles, we will explore the roles of the PMO, ITIL and CobiT in the business requirements-to-IT infrastructure within an organization and specific integration of these important frameworks.
Copyrighted by American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective copyright holders.
The joke goes something like this: What’s a Consultant? It’s someone who can’t get a real job and carries a briefcase!
Or, it’s someone in transition, i.e., just laid off and in between jobs.
For those of us who are “real” consultants (and we will define that for you), the jokes are particularly bad because, as we endeavor to provide value-added services to our clients, our clients don’t understand the difference between the Real McCoy and the Wannabe Clan.
As voting members of the Real McCoy’s, we will endeavor to de-mystify the differences and make it plain for those who are in search of an external expert.
The American Eagle Group has been an active member of the Independent Computer Consultants Association (ICCA) for over ten years. We have served as officers on the local Delaware Valley Chapter Board of Directors and served as the Vice President, President, Chairman, Treasurer, and now Secretary of the National Board of Directors in addition to serving as committee chairs and active participants in the discussion groups.
During our service to the ICCA, we have had frequent discussions – mostly heated – about the differences between a consultant, a contractor, and a wannabe. After all the hours of arguments and hot-air, we never really clearly defined the differences.
In a wonderfully written article written, “Are You a Real or Imitation Consultant,” Aldonna Ambler, CMC, CSP of Hammonton, NJ which appeared in the Professional Speakers magazine from the National Speakers Association (NSA), dispersed the smoke around the wannabe consultant. She worked with a client who became shocked at the number of people who called themselves consultants, but were not. Ambler listed some characteristics of the Wannabe Clan (I list them here verbatim):
Is that a list or what? Does your “consultant” fit that list or the opposite list – the list that would describe a consultant? When evaluating a person’s claim of being a consultant, do you have a list to measure them against or do you simply take their word for it?
Certainly “consultant” has a certain air, panache, mystic, and finesse that contractor or wannabe do not. So of course, all of us who sell our services to clients want to be known as consultants. But that leaves you as the client in a lurch. How can you tell the difference between the Real McCoy and the Wannabe? If the Wannabe has no real consulting skills, they must have something that causes you to think they are a consultant. When we are hiring outside expertise, we want to get expertise and not a smoke-n-mirror show that leaves us drained of money, time, and emotion. We want return on our investment – true, tangible return.
In the article, Ambler answered with a list. We will add some ourselves (so we can’t be accused of total plagiarism!). Ambler’s list:
Let’s expand on these ideas so we understand what they really mean.
The consultant should have appropriate credentials. Credentials come in different forms: educational, designations, research, practical knowledge and experience, and previous successes (and failures – a real consultant will learn more from failure than successes so you don’t experience those failures).
Does the self-proclaimed consultant have an advanced degree? Lest you think we are snobs, we do realize that years of experience can equate to formal education. In advanced degrees, students are not taught just more in-depth information, but a way of thinking and research. We at American Eagle Group possess advanced degrees and practical experience. We believe the lessons learned in research and thought-process during our advanced learning aided us to gained as much from our practical experience as we did.
Again, we believe there are many very intelligent and bright people who don’t have the advanced degrees that can run circles around us. The difference is, “How can you tell?” An advanced degree in the topic helps you qualify the veracity of the claimant’s claim. Anyone can talk a good game.
Playing a good game is another thing altogether. The advanced degree shows the player went beyond the expected and pressed further into his/her expertise.
Aside from the formal education, what further study or research has the consultant performed? Did their education stop when they received their diploma or did they continue through independent study? The continuing education helps keep the consultant’s information fresh and current. Otherwise, it becomes stale very quickly.
And finally, is the consultant’s advice based upon information found elsewhere so you know it has a foundational basis or is the information simply being designed on the fly?
In the case of American Eagle Group, we possess advanced degrees in Computer Science and Project Management. We have been named to several Who’s Who lists, elected to several boards of various non-profit associations, published numerous articles and whitepapers, and contributed to several anthology books. And we will continue with those types of activities because they keep our information fresh and expands our experience base.
Is the consultant’s information biased? Do they recommend one solution over another because of their favorable experience or are they receiving financial restitution for recommending it? Is this the only product they represent? You, as a customer, want unbiased, non-directed information. You want information that helps you make informed decisions, ones that align with your goals and objectives, not the consultant’s. The consultant should be void of any allegiance to a particular vendor or supplier. The consultant should walk into a client’s site with a clear slate as to any products or services that would fit the customer’s needs.
This does not mean that the consultant should know or understand the values of various competing products or services. They should clearly know the available set of solutions for the client’s situation. But it is the needs analysis derived from discovery that should drive the consultant’s recommendation. While the consultant might have his/her favorite solution, he/she should willingly set that favoritism aside to recommend the solution best fit for the client’s needs.
If the consultant should receive any type of compensation if the client purchases the consultant’s recommendation, the consultant should clearly designate that such compensation may occur. Again, the consultant must not let the potential compensation mar or influence his/her recommendation.
In most cases, we have not recommended a solution to a client prior to completing the needs discovery process. Recently, though, the client had requested a proposal for project management consulting and training. In our proposal, we did recommend a specific solution and substantiated that solution with reasons. We clearly stated that we do not receive any type of remuneration for the purchase of the proposed solution and we carefully stated that the recommendation was based upon market factors and future direction, and not because of any bias toward that particular solution. During our meeting with the client, we re-iterated that point and the client supported our recommendation and was appreciative of the rationale behind the recommendation. They were also glad to know our recommendation was not based upon any financial gain to us.
Facilitation is a fancy word for “make easy,” “make possible,” and “smooth the progress of.” We are not trying to diminish this important skill, but rather to help you understand a real consultant isn’t just technically savvy in his/her expertise, but knows other skills to get the job done. More importantly, they know how to put the ownership of the project back into the hands of the customer and not keep it to himself/herself so the client is always at his/her mercy.
We just got off the phone with a colleague who is trying to get a client back online with their small business server. The situation is dire because the server is not working properly due to multiple Trojan viruses, worms, and other viruses. And those are the simple problems.
The real problems are a result of the “high powered consultant” (and we are using those terms very loosely here) who originally configured the machine. The consultant used improperly licensed software (a.k.a., illegal) to create the server, illegally hosted websites on the server at the client’s expense and the consultant’s gain, registered the company’s domain address in such a way so only the consultant has the ability to configure the domain records, established several back door accounts with secret passwords in the event the client were to change the main password and a slew of other major and unethical offenses. Who knows what other data and information the consultant used to his advantage. Fortunately, the consultant has move onto other ground and has left the client in a lurch.
To top all this off, the client is really upset the machine is no longer functioning properly. The client is blaming my colleague for the malfunctioning even though the machine was not working properly before he came on-board (which is why the client called for a new consultant in the first place!) Yet the client stands firmly behind the expertise of the schlock consultant.
Facilitation requires we follow a five-step methodology: Problem/Opportunity Identification, Research, Design, Implementation, and Evaluation (presumably, the evaluation may identify something that requires another iteration of this process for continued improvement). A Real McCoy consultant will know how to manage this process and move you forward with tangible deliverables and results. A Wannabe won’t. And they may end up holding your family jewels as in the example above.
As the Real McCoy, we hold ourselves to a higher standard than the Wannabe. We subscribe to acting in the best interest of our clients, providing service that is top quality and ethical. We do not meddle with unscrupulous behavior and walk away for improper, illegal, or unethical practices, even when there is money on the table to be had. Our reputation is more important that any amount of money and we protect our integrity above all else. Not everyone has their price – some are priceless.
As real consultants, we carry the insurances, accreditation, certifications and licenses necessary to ply our trade. No longer do we simply have a business license and workman’s comp, we go beyond that minimum. We continue to grow our knowledge through formal education providing our clients with the latest information.
Currently, American Eagle Group belongs to two groups that hold us to a higher level of ethical code. We have been members of the Independent Computer Consultants Association since 1993. Before we can become members, we must read and agree to the Code of Ethics. Violations to that code could result in expulsion from the organization. The expulsion would severely damage our reputation and impact our business.
As professional speakers, we are members of the National Speakers Association. Again, we must read and abide by the Code of Ethics. Violation of this Code can result in expulsion. Again, it would damage our reputation, impact our speaking engagements which would impact our consulting business. Violation of either Code of Ethics would severely damage our business.
We put our clients first. Pure and simple.
To some, this may sound idealistic, but not realistic. The fact of the matter, there are many consultants that hold to these values. Sadly, there are many more that do not. Your job, Mr./Ms. Client, is to determine who is the Real McCoy and who is the Wannabe.
We hope we have given you some food for thought. The next time you hire a consultant, poke beyond their flattery and boisterous claims. “Where’s the beef!” as the TV ad many years ago proclaimed. Not everyone is as they seem to be. See what certifications, ongoing studies and other pedigrees exist to support their claims.
You’ll find them if you want to.
Copyright © 2006, David A. Zimmer, PMP All Rights Reserved
Recently while giving a presentation to a potential client, I used an analogy of crossing the street. I said:
“Project management is a lot like crossing the street. You can listen to others who have gone that way before and heed their advice. Look both ways, make sure the way is clear and cross before oncoming traffic hits you. Or, you can simply jump out into the street and see what hits you and then deal with the issues that arise.”
Sadly, too many people and companies people take the latter approach. From our study conducted in January and February 2006, we learned that 76% of project managers are not formally trained in project management. They are intelligent people, probably very good at what they were trained to do. But somehow, they were volunteered to manage a project and were not given the training to do the job properly. As a result, they struggled to make the project a success.
Experience shows that even though you are confident in what you are doing, it is always good to have someone watching your back and helping in areas that are new, even though they look very similar to the past. I learned this lesson, almost to my demise, while crossing a street in England. I was ready to cross a road, had my foot off the edge, when I was quickly yanked back to the curb. I was indignant at the person who would do such a thing. I had looked and the way seemed to be clear. I had successfully crossed many streets in my life. But just as I was going to say something to the person who yanked me, a car went whizzing by me and nearly clipped me. I had looked the wrong way! It would have been a fatal mistake. Another perspective on the situation saved my life. My indignation turned into gratefulness.
American Eagle Group provides that extra perspective. We have crossed many streets successfully – not always without incident though. We have the scars to prove it! Through our “coaching” services, we help you make more informed decisions. We help you see the way more clearly.
One of our clients used our service and saved over $5 million dollars! They were embarking on a new marketing campaign. They wanted us to provide a sanity check on the project plan and roll-out. While the intent was to make sure the “project management” was sane, our understanding of the market and the broader scope helped us to show them the fallacy of their thinking. Yes, we could have helped them manage their project successfully, but our greater understanding of project management show us that the stakeholders’ expectations would not have been met properly – a successful launch of the product and the wise use of $5 million. The project would have been a failure and a waste of the valuable $5 million.
Another client asked us to determine how they would make money from a particular project. The project had already been underway for two years with more to follow. The annual budget for the project to date was $90 million ($180 M total) with increased budgets to come. So it was critical to understand the profit potential for such a project. After careful analysis of the business plan, we determined that expenses on the project were 77% of the potential revenue. That 77% of the revenue represented operation expenses and did not include the overhead of the ongoing development of the project or other corporate overhead! As a result, the project would never had made any money. We recommended that the project be cancelled based upon the financial analysis.
We felt like that person who saved my life in England by yanking me back from a speeding car coming for a direction I was not looking. These are just two examples of times when people, confident in what they were doing, looking the wrong way when something was coming from the other direction. We were there to help save them from certain disaster.
So, the next time you wade out into the street, make sure someone is watching your back!
Copyright © 2006, David A. Zimmer, PMP All Rights Reserved