Skip to main content

Tag: Technical Project Management

How Business Architecture can help Project Managers to be successful.

Written by Scott Comte on . Posted in Articles. 6 Comments on How Business Architecture can help Project Managers to be successful.

One of my favourite questions to ask candidates when I was in the executive recruitment game was “In your experience what makes a successful (insert name of role I was recruiting for).”

It was a great catch-all question as the answers provided gave a very good indication of where the candidate sat on the professional continuum for the role in terms of experience, knowledge, and competence. It also served as a good way to educate the recruiter on the varied aspects of the role. One of the key insights that I discovered through this practice was how much different professions have evolved over time. No more so than the role of Project Manager.

The Project Management profession is in growth mode. Research by the Project Management Institute (PMI) indicates that the number of roles globally will grow by 33% in the next 10 years with forecasts that there will be 88 million people working in a Project Management related role by 2027. In the research the head of the PMI in China, Bob Chen described the evolving role of Project Management in the following terms:

“As the business environment today is becoming increasingly complex and fast-changing, it has brought higher requirements to project managers. Project managers today should not only have a firm grasp of basic project management knowledge but also possess strong leadership, including skills in conflicts resolution, negotiation, stakeholder management as well as capabilities in strategic and business management,”

Breaking this down further Moira Alexander in CIO Magazine identified six key traits that differentiated good projects managers from the rest of the pack.

  1. Be a strategic business partner – be able to clearly evidence how your project is contributing to the organization’s strategic goals.
  2. Encourage and recognize valuable contributions – leverage the benefits of collaboration
  3. Respect and motivate stakeholders – this particularly important when dealing with project sponsors and business stakeholders.
  4. Be fully invested in success – own the project outcome.
  5. Stress integrity and accountability
  6. Work in the grey – effectively deal with the ambiguity and complexity that is the modern business environment.

Historically it used to be that you were either a technical, e.g., Information Technology (IT) Project Manager or a Business Project Manager. The traditional IT Project Manager was responsible for the delivery, planning, organizing and delegating responsibility for the completion of specific information technology outcomes. In contrast, the Business Project Manager delivered operating model projects with little or no technology. Where there were technology changes they ensured that IT systems met the business requirements of users/ stakeholders and the system and operating model changes were successfully adopted to achieve business benefits.

While these are very simplistic definitions, it evidences that there were distinctly different skillsets required to deliver on each of these roles. Technical Project Managers came from technical backgrounds such as development, infrastructure, or engineering and they had strong technical knowledge of how a system or product should be built. The Business Project Manager would most likely come from a functional role within the business from areas such as marketing, operations or finance. Each type of project manager’s knowledge was informed by their business experience, training, and development. They would often cross-skill on projects and may have developed broader professional knowledge through additional studies such as an MBA, but fundamentally they were a product of their functional experience. Over the last 20 years, these two distinct project management professions have been slowly morphing into what we know today we know as a Project Manager.

Advertisement
[widget id=”custom_html-68″]

I believe too often project managers have been forced to work with unnecessary ambiguity and complexity. This is due to the inability to align their project outcomes to the strategic objectives of the organization. This is something that you don’t develop through either business functional or technical experience and is an attribute that both Moira Alexander and Bob Chen see as a key competency to being a successful project manager. It is interesting to note that they believe the key to successful project management is to not only have the ability to align your project with strategic outcomes but also to be able to communicate effectively to your stakeholders how you are supporting them to deliver strategic outcomes! This is supported by PMI research that has shown that one of the key contributors to project success rates is the level of engagement of executive sponsors. If Project Managers can effectively engage and motivate these stakeholders their ability to succeed will be greater.

Formal Project Management development pathways such as Prince 2 and Project Managers Body of Knowledge (PMBOK ) provide excellent methods to execute a project while bodies of knowledge such as Business Analysis Body of Knowledge (Babok ) provide excellent insights and tools to assist with requirements gathering. But to link project outputs to strategic objectives, I think that we need to draw on the skills and knowledge of a different profession, Business Architecture.

Business Architecture, through the technique of Capability Based Management, allows a Project Manager through business-led collaboration to translate the organization’s strategic objectives to project level outcomes. This is done by defining the Business Model and Value Streams required to deliver those objectives and then further breaking these down into the different capabilities (people, process, technology, and data) that the outcomes of the project will enhance or establish. The artifacts and tools used to do this can be used to provide a level of traceability that the Project Manager can use to show how their business case aligns what is proposed at the project level to what is important to executive stakeholders. Also, it can support the motivation of project teams as individual team members can see how their contribution adds value to the bigger picture.

Business Architecture assists project managers and their collaborative teams to be fully invested in success and accountable (owning the project outcomes). When a project output can be traced to the establishment of or improvement in a capability (s) that has a demonstrable impact on a value stream, then this will motivate business stakeholders. The tools of Business Architecture such as the Business Motivation Model, Business Model Canvas, Value Stream Maps and Capability Maturity Roadmaps are excellent ways of communicating complex project activities to executive stakeholders.

These techniques, tools, and artifacts are equally effective at providing a supporting framework for project team members as they can align their value-adding activities to specific areas of capability improvement. I believe that having access to these types of frameworks will become increasingly important to Project Managers as the adoption of Agile practices increase. One of the core principles of Agile is to be continuously delivering value. In many organizations what constitutes value can be quite subjective when looked at from a Project versus Business perspective. Having a defined business architecture allows Agile Project Teams to map the outcomes of their iterations to capabilities and value streams and consequently strategic objectives. Through this mechanism, Agile Project Teams can communicate to their stakeholders how their activities are adding value.

I started this piece by asking the question what makes a successful project manager. The answer, while somewhat self-evident, is someone who delivers the outcomes the organization wants/ needs. It is how these outcomes are defined that has had the most impact on the development of the project management profession. Historically success used to be delivery of projects on time, on budget and meeting quality requirements within the defined scope. Now the requirement is to deliver demonstrable business outcomes. This has thrown up new challenges for Project Managers as they need to be able to provide their business stakeholders, particularly executives, with the confidence that they not only understand what business outcomes need to be achieved but also communicate how they are going to deliver these outcomes. This ability to link business strategy to project execution is one of the greatest benefits of Business Architecture, and I believe that Project Managers who can draw on these techniques, tools, and methods will position themselves as a strategic business partner over the next ten years and at the same time have a rewarding and fulfilling career.

Risk – Early Conversations Make For Better Projects

Written by Andrea Brockmeier on . Posted in Articles. 6 Comments on Risk – Early Conversations Make For Better Projects

Every project and every project stakeholder deserves some risk management, no matter how small or simple the project.

That is a sentiment I often share with my project management students, inspired by an experience I had managing a small project years ago.

I was assigned to a project that had to be delivered in a short period of time. Fortunately, the product was very familiar to me and the team, and we had done similar types of projects in the past. Further, team members already knew each other and the SMEs in the organization who would be providing support.

Even though I had worked with the team members previously, I had concerns about one of them, Jon, because we hadn’t used him in this particular role. I did not think that what he was providing on the project played to his strengths. But since no one else seemed concerned and we were in a rush, I decided to move ahead without any discussion around project risks. I didn’t want to be a nay-sayer. We had done this before and these team members were familiar with the product, the organization, and each other. What could possibly go wrong? I figured we would just cross that bridge if, and when, we got to it.

Well, many weeks into the project, we got to that bridge. Jon produced his deliverable – and it was a mess. Way worse than I could have imagined. Total show stopper. What was even messier, however, was having to tell my sponsor about the problem. As much as anything, I was frustrated with having to present what appeared to be a “surprise” to my sponsor. I wasn’t looking to say, “I told you so,” but the burden of the mad scramble to respond felt heavier than it no doubt would have if the sponsor and others had been aware.

Advertisement
[widget id=”custom_html-68″]

Many late-night phone calls and floor pacing ensued along with considerable stress just trying to figure out how to communicate what had happened. Actually, developing a response to the issue felt entirely secondary to the challenge of communicating that it had occurred. I couldn’t see clear to a solution because I was so concerned about my sponsor’s reaction.

For many, the reaction to something like this on projects is often emotional and poorly scaled. Further, the inclination is to spend time figuring out how a problem could have happened, what could have prevented it, what should have been done differently, etc. While the intention of those reactions isn’t always to place blame, they often leave people feeling like they did something wrong and it can create negative energy on the project. That was certainly the case with this project.

Looking back, a conversation with my sponsor about my concern would have better served the interests of the project and the organization, as opposed to ignoring it in order to move faster to meet an aggressive deadline. In fact, I am certain that we would have accepted the risk and not done anything proactive about it. Talking about it early on, however, would have changed the tone of the conversation once it did happen.

Early discussions about potential threats serve to get concerns in the open so that if they do occur, the reaction from the project manager, sponsor, and others can be more constructive and get to problem-solving faster.

It’s the conversation that matters, and having it early about potential problems is a lot easier than having to initiate a conversation mid-project after an issue has already created problems. They help create a project culture of openness and trust. Most importantly, better project decisions get made, resources are used more wisely, and project tempo is sustained when the risks do occur.

I learned a lot from that experience. No matter how small, how familiar, or how “been here done this” I feel about a project, I make sure we take some time early on to talk about what could go wrong. That makes risks a safe topic, and one that’s likely to be revisited throughout the project – in a tone of partnership.

How about you? What has your risk management experience been on small projects?

42, The Douglas Adams IT Project Management Experience

Written by Donato Piccinno on . Posted in Articles. 3 Comments on 42, The Douglas Adams IT Project Management Experience

According to Douglas Adams the famous author of The Hitch Hikers Guide to the Galaxy 42 is the answer to everything.

The story goes like this. The most advanced race of beings in the whole universe decide to build a super computer to answer the ultimate question. They wait in anticipation for the greatest technical marvel the universe has ever seen to provide the answer. After the wait is over the answer is 42. The answer is so clever the most advanced beings in the universe cannot understand it. Rendering their creation absolutely useless. The story is a cautionary fable in the faith we place in technology and hyperspecialism to provide the answers to make the way we want to do things easier. Douglas Adams is more than an author. He is adept at conveying the outcomes when the human condition meets technology and process. The unintended consequences when humans do the human thing. Which is to do the completely unpredictable things the technology and process does not expects us to do. How very dare they! The audacity of it all! Douglas Adams quotes and thoughts can all be observed in action at the point IT solutions are conceived in the word of Enterprise Architecture then project managed into use by the real world. It’s the point where technology, human nature and process meet. Anticipating these outcomes well and things go well. A lack of anticipation normally results in unintended consequences. Where IT project delivery is concerned the same old story statistics on IT project performance from Standish and Gartner show a Douglas Adams observation in action.

Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.

We are classically trained to formulate the delivery of IT solutions with our scientific management head on. The ghost of Taylorism permeates every single way of working while delivering an IT project. The consequences are plain to see in the repertoire of Douglas Adams quotes. Missed deadlines, services that don’t meet needs, waste, cyber crime, disillusioned workforce and technology that fails to perform the moment it is exposed to the real world.

A common mistake that people make when trying to design something completely fool proof is to underestimate the ingenuity of complete fools.

I was actually inspired to write this piece following a meeting about rolling out a few laptops and phones. The experience was most humbling and ego destroying. I came away from that meeting kicking myself for falling for the illusion of control scientific management and technology can instil in us. For the meeting we’d come up with this text book rollout process for network, printing, HR, pcs, laptops and phones. Any methodical process type person would not fault it. But it had two fundamental flaws. For the process to work and give the final user the experience they were looking for everyone in the process had to follow the process. The key principle was 20 days prior to the IT solution going live the process needed to know the name of the employee. But in the real world a person could be employed on the day they needed the solution. Without the IT solution that employee would be sitting around for several days as a new starter request made its way through the process. The 2nd fundamental probably caused the team to miss the 1st fundamental flaw. The process was designed by experts who had no idea what it was like to be the user on the day they needed the IT solution. We knew what they needed from a functionality perspective but had no idea what it was like to be the user. So who were the ingenious fools in the Douglas Adams quote? The end user not following the process? Or the team that designed the process. IT project plans consist of activities from many different domains. Our plans are full of specialists i.e. legal, procurement, engineers, Infosec, HR, developers, architects, user managers, finance and the ITIL brigade. All insisting on something done in a certain way. I’m sure their motives are ulterior and it is always for the good of the company. But there is an inconvenient truth my comrades can fail to grasp. Unless experts design solutions or process from the point of view of the end user what is being insisted on is as much use as a chocolate teapot.

He was a dreamer, a thinker, a speculative philosopher… or, as his wife would have it, an idiot.

Again it’s the human condition and nature at work. As IT project delivery experts we like to think we are right even when we have zero experience in what the end user experiences. That makes anyone who thinks like that an idiot. The way around being an idiot during delivery of an IT project is to constantly check for experience shortfall within the team designing the process. A lack of experience in the experience of the end user in their operational environment is the experience shortfall. Secondly, involve people who have done what you are trying to do. Fail fast by rehearsing implementation scenarios early and often. Particularly, where the rollout environment has the following context:

  • Accessing the solution from or connecting to a heterogeneous network
  • Rollout sites are remote
  • Users are not tech savy
  • There is an inter generational gap between the project team and the end users

To give real service you must add something which cannot be bought or measured with money, and that is sincerity and integrity.

Advertisement
[widget id=”custom_html-68″]

Back to our user who has just been employed and walked in on the day of rollout. With my compliance and process adherence hat on I could say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager.’ What if a whole organisations existence is about that particular type of user being empowered from day one. The beating heart at the heart of the house so to speak. The process compliance world tends to have a transactional relationship with the real world. As long as the real world behaves in a way that is a valid transaction. Everything is #peachy. If not, the tendency will be to try and get the real world to change. Which is fine until such a stance becomes dogmatic or a non-starter because the real world cannot be changed. An IT project delivered in that kind of culture is unlikely to perform on many fronts. Usability for ease of use and ease of deployment will suffer a dip in a performance. What if we rethink the project plan to rollout an IT solution based on principles or probity, sincerity and integrity? What if we view the user experience of receiving an IT solution as a customer experience? Would we end up with an outcome where on the day we say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager to go through the process.’ No, a customer of the project would have their IT solution ready at the point the needed it.

Thinking of a rollout process from a perspective of customer experience management, probity, sincerity and integrity results in handovers of IT solutions where all user personas and real world circumstances get considered. Such thinking challenges the way IT solutions are designed to be accessed. For example, take cached credentials. Great from a security compliance point of view but as much use as a chocolate teapot in the rollout scenario below. With cached credentials the device has to be sent back to base.

  • Heterogeneous network
  • Remote sites
  • User details not known until the day they need the laptop or PC.

A prime example of the technical world not understanding the real world. Leaving the project wide open to the following outcome. Observed by Douglas Adams at the touch point between human nature, the human condition, technology and experts who lack understanding of the real world. The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.

7 Tips on How to be a great Project Manager

Written by Jasmin Ali on . Posted in Articles. 70 Comments on 7 Tips on How to be a great Project Manager

Project management may sound easy, but taking up the role of a Project manager requires sword play with the right wit.

Many a times, when the Project Manager is at fault or does not abide to an employee’s needs, the company is bound to lose a valuable resource. A good Project Manager is hard to find, but a great Project Manager? It is harder. Understanding the goals of the company, project deadlines, managing time effectively and being a good boss to employees can be easy if these seven tips are followed:

1. AVOID MICROMANAGEMENT

Project managers tend to get extremely observant and controlling when a project is assigned to their team. It might be because of irrational deadlines, lack of time, underestimating the power of their resource and panicking about proving their position. This leads to constant micromanagement where Project Managers constantly nag or monitor employees and their work, breathing down their shoulders through the entire day or week, until the project is done and dusted. Sometimes, employees are never given an off and might be asked to work during the weekends which would eventually drain them out. A great Project Manager understands that every employee is human enough to have their own time and space to figure out how much they can deliver and how fast they can. Employees should be given their own freedom to work around schedules and plan out how they can deliver before deadlines. Micromanagement only demotivates employees and puts them in a position where they are rendered as incapable of deliveries unless monitored. A great manager avoids micromanagement like the plague and uses it when and wherever necessary.

2. EVALUATE PRIORITIES

Many project managers follow agile methodology where different parts of the project that have various dependencies are mapped out and listed in the beginning. With time, priorities change. Re-evaluating priorities in a periodic manner and changing work deliveries is important. Priorities are never the same throughout a project and it takes a great manager to find the loops and holes of it, to deliver projects on time.

3. MANAGE TIME EFFECTIVELY

Time management is a great manager’s number one priority. Maintaining a balance between being productive during the productive hours at work and allowing employees to have their free time is important. Project managers must make sure that employees get the work done on time, without stressing them out by pressurizing them. Any good resource would work efficiently when the work is handed over to them, without the need of a push. Figuring out the good and the bad egg from the team is crucial. Laying out tasks and targets for employees to meet during each day is a good way to start.

Advertisement
[widget id=”custom_html-68″]

4. COMMUNICATION IS KEY

Good communication is good project management any day. The ability to communicate to the stakeholders as well as the team effectively can drive a project to be delivered on time. Giving out broken promises to stakeholders and urging employees to complete their tasks as promised would cause huge problems to the team as well as to the clients. Being an effective communicator between the team and the clients is important.

5. UNDERSTANDING PSYCHOLOGY

They say that great project managers understand their employees. Keeping track of how much an employee is able to deliver, how fast they can and what fields and skills they are good at is important. The ability to drive employees to complete tasks they love accomplishing and are good at. Knowing your team’s strengths and weaknesses and allotting tasks similar to what they can and cannot do is vital.

6. EQUIPPING THE TEAM

Technology is an ever-evolving stream of today and to be knowledgeable in all kinds of software and technology is a challenging task. Being up-to-date on technology and exposing your team to the existence of such, is important. Project management training for employees to be knowledgeable on various fields that are emerging in the current technology-driven world can bring the company a lot of projects and profit.

7. GREAT PROBLEM-SOLVING SKILLS

When there’s a project assigned to you, there will be problems assigned to you as well. These problems can arise at any time of the project. Problems can vary from being related to the employees within the team, health-issues or emergencies that occur mid-way or at the time of delivery, misinterpreting requirements, missing out on SLDC processes, bug issues and problems that are completely unexpected. Being a great problem-solver by understanding what is to be done at such situations is the best trait of a great project manager. A great project manager works towards the success of the company and its products and it is vital to know how to handle unexpected situations in a witty way.

BEING PREPARED

Being a good project manager takes time while being a great project manager takes experience. Using the right kind of skill at the right time and handling organizational problems takes time in understanding what each member of the team is capable of. Believing that your team can perform better at every step of the project is crucial. Preparations for the worst can improve problem-solving abilities.

SUMMARY

Understanding the project strategy vision, bringing out the best out of your team, timely delivery of projects, being an effective communicator, solving problems, preparing, disclosing, bargaining and closing projects can go a long way in tuning your project management skills. Looking into administrative details of projects is also an area that can’t be missed out. Project management takes planning, leading, implementing and collaborating.

Any good project manager can become a great project manager any day. Taking a keen interest in your development, the team’s as well as individual development is an added asset. Keep your doors open for employees to put in their thoughts and worries that serve as barriers to meeting deliverables or taking up projects. Delegate tasks and sub-tasks to get work done in a simple and easy way. Finally, a great project manager works with the team and accomplishes their mission.

“You don’t have to be great to start, but you have to start to be great someday”.

Why People Fail the PMP® Exam

Written by Emil Tarka on . Posted in Articles. 4 Comments on Why People Fail the PMP® Exam

Failing the PMP® Exam is a negative experience, which I would not wish upon anyone.

After teaching PMP® Prep for nearly 10 years, there is nothing more rewarding than receiving an email from a student, saying, “thank you; I passed the exam”. Unfortunately, occasionally a learner will reach out to say that they didn’t pass the exam.

Fortunately, this is a very rare occurrence. However, when this does happen, it is as devastating for me as it is for the learner, and a part of me says, “what did I do wrong? Is it the material I used? Was my instruction method flawed?”.

I have taught thousands of students, and after some substantial thought and data analysis I have concluded the following five reasons as to why someone may fail the exam:

1) Lack of Preparation:

It is strongly recommended that a learner scores at least 85% on a full-size practice PMP exam. Many learners take short pop quizzes composed of 20-50 questions, score well on those, and then determine that they are ready to write the PMP exam; this is not the case.

Solution: Other than the obvious (preparation), do as many questions as it takes to get you to the 85% threshold.

Advertisement
[widget id=”custom_html-68″]

2) Difficult Exam:

PMP® Exams are random; some are easier; others are more difficult. Also, different exams have a different focus. Some exams focus more on change management; others on mathematical calculations or procurement. Depending on your familiarity with a knowledge area this could be one reason for failure.

Solution: Eliminate the possibility of having a “weak” knowledge area by mastering all knowledge areas.

3) Turning the PMP® Exam into an Earned Value Management (EVM) Exam:

Let’s be honest; math can be challenging for some PMP® candidates. This is quite understandable if you don’t work in a field which requires you to crunch numbers on a regular basis. Some learners devote an unnecessarily large amount of time to memorizing the EVM formulas.

Solution: Don’t spent any more than 10% of your study time on memorizing EVM formulas.

4) Inadequate/no Brain Dump:

Brain dumps usually include EVM formulas, profit forecast calculations, and contract types. Most PMP® trainers recommend that students memorize various formulas and factoids, and write them out in the exam room prior to starting the exam. Writing out the brain dump is essential as it relieves the pressure from focusing on memorization and allows the candidate to focus on the PMP® questions instead.

Solution: Access a well-developed brain dump from a reputable trainer.

5) Second-guessing Yourself:

Frequent second-guessing of your final answer on the PMP® Exam is either an indication of having insufficient knowledge or sheer hesitation caused by stress. Waddling between two answers is frustrating and a bad use of time.

Solution: If knowledge of exam content is not an issue, choose the answer which strikes you as being the most likely at the first instance. If knowledge is the issue, you are not ready to be writing the PMP® exam, and consider doing more practice questions.