Getting buy-in from your team and keeping everyone on the same page is not easy. But if you can do these five things really well, then your teams will thrive and your projects will come to completion...
1. Listen Intently to Your Team Everyone likes to be heard. This is especially true when people are talking about their opinions on the best way to complete a project. It's important for you to listen intently to everyone on your project team.
Does this mean that you will do everything your team suggests? Of course not! That would be impossible as what one person suggests may be in direct conflict with someone else's suggestion. But, it does mean that you have taken the time to listen to someone's ideas, asked them questions, and then taken the time to explain whether or not their ideas will fit into the big picture of the project.
2. Over-Communicate with Your Team How often have you heard "I didn't know that" from someone on your team when you know the topic was recently discussed at a meeting you all attended? This is a common occurrence that has been the nemesis of many project managers.
Take a lesson from product marketers. There is an adage that says someone has to hear something up to 7 times before they take action on the message. Marketers will present the same message in different ways, at different times, and in different formats until something finally clicks with their potential buyer. You need to do the same thing as a project manager. Hopefully, you won't have to repeat yourself 7 times, but look for opportunities to make sure your team members clearly understand your message and always err on the side of over-communicating.
3. Create (and Stick to) Clear Ground Rules for Your Team Didn't you hate it as a kid when you were playing a game and the rules always seemed to change? Just as soon as you thought you had figured out how to play, someone came along and said things were going to be done differently. What's worse, this was usually to your detriment!
That was bad enough as a kid, but it really gets frustrating when you are an adult trying to complete your project. It's your job as a project manager to create reasonable ground rules and make sure everyone plays by them. These reasonable ground rules include what reports are due and when, how disagreements or conflict will be resolved, expectations for individual performance, and when issues need to be escalated. It's equally as important that you maintain consistency across all team members on the application of these ground rules and not change them on a whim. One word of caution...keep ground rules to a minimum. You don't want to overwhelm your team with a ton of rules that do nothing more than bog people down and prevent work from getting done.
4. Change Your Management Style as Your Team Evolves There are a number of development stages that project teams will go through as they start working together. These are typically categorized as Form (coming together), Storm (initial conflicts), Norm (things begin to smooth out), and Perform (the machine is up and running).
To effectively manage a project team it's important that you understand the behaviors, cares, concerns, and anxieties of team members in each phase and manage accordingly. For example, during the Storm phase of group development you will be serving as more of a moderator, facilitator, and possibly even mediator. You will be very hands-on and spending an inordinate amount of time with team members as they work through these issues. Once they have reached the Perform stage, however, you want to back off and give everyone their room and independence to get their work done with minimal intervention.
5: Empower Your Team Members Here's a sure-fire way to get people to quit in utter disgust and frustration...give them a task to do without the proper level of authority to get it done. You can inadvertently do this a number of ways. The first is by making them check back with you every step of the way to ensure they are making the right decisions. This is a morale-killer and screams "I don't trust you!" The second is to give them a task that is beyond what they can handle themselves at this point in their career. You are only setting them up for failure and embarrassment if they don't have the skills necessary to get the task done. Remedy this situation and set them up for success by mentoring them through the process and build up their confidence.
So that's it. If you listen to your team, over-communicate, create and stick to clear ground rules, adapt your management style as the team evolves, and empower them to get things done you will find that your project team can't wait to work with you on the next project you manage!
Top Six Requirements Gathering Tips
Top six requirements gathering tips (techniques really):
Interviewing. One on one conversation with stakeholders and users. A key piece of information to get is why. The most important thing to remember when interviewing is to ask open ended questions. When our interviewees tell us what they want, and how they want it (good open ended questions), make sure to capture the information of why they want it.
Brainstorming. Brainstorming is a very effective technique for idea generation. Brainstorming is most effective when there are two phases – creating ideas and validating ideas. The key to making brainstorming work is to not criticize, remove, or prioritize any ideas during the creation phase. A bad idea may lead to a brilliant one, but if people discount it, it won’t lead anywhere. After we are done creating ideas, we can move into the validation phase, where bad ideas are removed and good ideas are prioritized. Concept maps provide a great way to organize ideas as they are being prioritized. Here’s a post on how to use brainstorming for requirements gathering.
Documenting use cases. Creating and reviewing the use cases required to enable the high level goals of the system is effective at identifying oversights in the business requirements. We’ve found that informal use cases provide the best return on invested effort at the early stages of elicitation – they are easier to iterate, and provide less risk of getting caught up in the details of early thought processes.
Prototyping. Software is often designed to change the way people work. Users and business owners should not be expected to be able to visualize the new software. Users usually don’t know what they want until they see something they don’t want. They may need to use the new software (with its associated process changes) before they discover additional valuable functionality and features. Prototypes can be simplified implementations, or even paper prototypes. When users interact with the system (even with something as simple as wireframes printed on paper), they are able to envision how they will use the system. These interactions can identify oversights in the requirements. The prototypes can also be used in discount usability tests.
Analyzing documents. There are usually an abundance of business plan, project plan, market analysis and existing system documentation. Reviews of those business requirements documents provide context and insight into the problems being addressed by the new software. This context provides an understanding of the domain as well as great starting points for interviews and brainstorming topics.
[Bonus] Business Process Modeling. Creating diagrams that document the business processes for which we are gathering business requirements can be very helpful in discovering missing requirements. They are also extremely effective at communicating scope. Business process models can help reach a common understanding with stakeholders and developers about what is intended to be accomplished by the software. Creating a business process diagram and reviewing it with the customer is also an extremely effective way to apply active listening skills.
Who Should Lead the PMO?
We all know that there are many different models for PMOs--different functions, different reporting structures, different organizational alignments, etc. There is no perfect model for a PMO, but is there a perfect model for a PMO leader? In this article I want to try and build a profile for a PMO leader, look at how different strengths and opportunities affect the PMO and match skills with structures. Just like there are multiple successful PMO models, there is no single right model for a leader--but there are some common themes.
Subject matter expert or skills expert?
There’s an age-old debate in project management about whether you need to be a subject matter expert on the type of project that’s being undertaken--do you need to be an IT expert to manage IT projects, for example? I’ve got plenty of opinions on that, but that’s a different article. In PMO circles, I think that the issue is clearer--the PMO is about project management, and that’s where the expertise should be, not in the specific discipline that the projects are about. In some cases, this might be obvious--in a company-wide PMO there is unlikely to be a “discipline expert” because every discipline is covered, but that’s not always the case.
I have seen a large number of PMOs that were established in functional areas, particularly in IT. In many cases, this is a direct extension of the office of the CIO--the CIO keeping the projects close to themselves as they have such a big impact on their department. In this model, the person asked to head the PMO is often the CIO’s trusted lieutenant--the manager in their organization that they rely on to handle key initiatives.
If that person is an IT guru rather than a project management expert, that may lead to a very different style of PMO--one that is focused a lot more on the projects and less on the discipline of project management, effectively becoming a project control office. That may be acceptable depending on what the goals of the PMO are, but it needs to be a conscious outcome rather than an accidental result.
Project management is not enough
A strong knowledge of project management is clearly a prerequisite for leading a PMO, but many PMOs make the mistake of thinking that PM skills are enough--the world’s greatest project manager is not necessarily going to be a good PMO leader. The head of the PMO is not going to be managing projects on a daily basis, and while they may be the “go to” person for advice on solving project management problems, that is only part of their responsibility.
Running a PMO is likely to involve ownership of processes and tools, managing an operational budget, making decisions around resource allocation and utilization, and of course leading people. While some of these skills can be taught, the ability to apply those skills appropriately comes from experience and good judgment, and to my mind that is what defines what a PMO leader needs to be--they need to be a good businessman or woman.
The traits of a great PMO leader
I like to think of a project as the “business in microcosm”--virtually every discipline required in running a business is involved in running a project. For a PMO, that is even truer: The head of a PMO has accountability for all of the project elements that their project managers are looking after, plus the need to run the business unit itself. This ensures that the right PMs are assigned to the right projects; that the tools and processes are maintained and improved; that budgets (project and department) are managed appropriately; that staff are developed, encouraged and motivated, etc. That takes a pretty special kind of person, and here are my traits for the “perfect” PMO leader, in no particular order (except perhaps for the first, which is head and shoulders above the rest):
A sense of humor with a sense of perspective. Projects can be stressful environments, and the leader who can’t put the challenges into context with a smile on their face is not helping the situation. I once worked for a PMO leader who got very riled up with every project issue--he would take every issue personally, would always assume the worst outcome and would also treat problems like the end of the world. Project managers felt even more pressured and the environment was not a good place to be. More significantly, he had a heart attack at 42 and never made 43. It’s “just” a job, and you need a leader who can not only see that, but create an environment where the project managers remember it.
Exceptional communication skills. PMO leaders need to be able to communicate comfortably with C-level executives and junior project resources equally well. They need to be able to understand that different personality types need different communication styles, different mediums, different levels of detail and different amount of time to understand and process information. They need to be able to tailor their message to those styles, and they need to be able to adapt to the style of others rather than expect people to adapt to their needs.
“Appropriate length” leadership. I prefer this term to arms-length (which too often means “hands off”). Heads of PMOs will never be successful if they are micro-managers--that just makes them project managers, and they won’t be successful if they are remote. They need to provide guidance and encouragement proactively (not just “have an open-door policy”) and recognize that not everyone will feel comfortable asking for help--sometimes the need has to be recognized and the assistance offered. Above all, they need to recognize that different people need different leadership styles.
Self awareness. Leaders don’t have to be experts at everything, and in the case of a PMO that’s especially true. But they need to surround themselves with experts where they have skills gaps, and that means recognizing your limitations. If they aren’t a process expert then that’s okay--they just need to realize that and appoint someone to look after the management and improvement of the project methodology, tools, etc.
Broad project management expertise. That statement is carefully worded--PMO heads aren’t actively managing projects, so if their project management skills aren’t as deep as they once were (if they have become “stale”), then that’s not necessarily an issue. What they do need is a broad understanding of project management situations, approaches, techniques, etc. In a perfect world, there’ll never be a situation that the leader hasn’t seen before. They may not have the answer, but they can say “I’ve been in a similar situation, have you thought about trying…”, or “When I was facing a problem like this, I tried…”
Superior functional management ability. PMO leaders are still functional heads and they need to have a good handle on the management of that function--budget control, succession planning, resource utilization, etc.
Strategic thinking. A PMO leader who cannot think strategically will never be able to advance their discipline, and that will ultimately lead to stagnation. A PMO cannot simply “stand still”; it is expected to continually improve the way that it operates, integrate lessons from every project and become more efficient with every initiative.
Conclusion Don’t try to compare the head of your PMO and consider them a “failure” if they don’t meet all of these qualities; no one is perfect. However, this isn’t a bad list of skills to aspire to, and if you have a PMO leader who comes close to these traits then I suspect that you are working in a successful organization that is a pleasant place to work.
What is a Non-Functional Requirement?
Functional requirements define what a system will do. Non-functional requirements describe how the system will do it. Non-functional requirements characterize the behavior that is required in functional requirements.
Construction Design Build Guide
Design-Build is a contracting procedure used to accelerate procurement of a contract by allowing the contractor to begin construction before the final design has been completed. This guide will enable administrators to evaluate the feasibility of using Design-Build for potential projects based on previously completed projects.
As world economies evolve into service driven and globally oriented economies, many new risk factors have come into consideration.. Financial risks such as currency fluctuations, human resources in foreign countries, major disasters such as Tsunami, earthquakes, floods etc and factors such as fluctuations in distribution channels, foul play in corporate governance are just few of them. ERM has emerged as one of the most important tools for managing compliance and avoiding the risk of non-compliance.
ERM can be defined as follows:
ERM is the discipline by which an organization in any industry assesses, controls, exploits, finances and monitors risks from all the sources for the purpose of increasing the organization's short and long term value to its stake holders.
Overview of ERM
For monitoring the performance of an organization with respect to corporate objectives, it is imperative to form control mechanisms that enable the identification of risks and which meet the predefined objectives. Two complementary frameworks for internal control mechanisms have emerged as the de facto standard through which companies should be regulated and measured. These are called as Turnbull framework and COSO framework. The Turnbull framework is based on 1999 publication Internal Control Guidance for Directors on the Combined Code. The COSO framework is based on 2004 publication on Enterprise Risk Management Integrated framework. Both the frameworks suggest that base of effective system of governance and internal control is proactive, efficient and sustained ERM.
The Framework of ERM can be summarized as follows
Establishing context
Identifying the risks
Analyze/Quantify/Integrate risks
Prioritize risk
Treat/Exploit risks
Risk assessment/ Treatment
Risk Modeling for an Enterprise:
Risk modeling refers to the models and methods used to evaluate risk and performance measures. Most organizations usually possess a simple financial model of their operations that describes how various inputs (i.e. risk factors, conditions, strategies and tactics) will influence the key performance indicators, which are used to manage the organization. Most of the structured financial models are deterministic models as they describe the expected outcomes from a given set of inputs without considering the probabilities of their outcome above or below the expected values and these models can be converted into stochastic models by treating certain inputs as variables.
There is a wide variety of risk modeling methods, which can be applied to a given task. They can be classified on the basis of the extent to which they rely on expert input as against availability of historical data. The classification can be given as below.
(1) Methods which primarily rely on the availability of historical data
a) Empirical distributions b) Regression c) Extreme value theory d) Stochastic differential equations
(2) Methods which primarily rely on expert input rather than historical data
a) Delphi method b) Influence diagrams
Sometimes the expert judgment is used to develop the logic of the model for supplementing the missing data besides the available data from the historic records.
(3) The methods which rely on both the expert input and historical data
a) Bayesian belief networks b) Fuzzy logic
These models are basically suited for the operational risk and the strategic risk.
Sometimes risks in the enterprise are related to each other. To predict the relationships which exist between two risks can be done through covariance matrix or through structural simulation of the model of an enterprise. As an example, using the economic scenario generation model, inflation rates and interest rates can be generated. The risk integration is also possible to analyze through structural simulation of the model. This allows a person to capture the dependencies among variable inputs in a simple, accurate and logically consistent way of the model's cause/effect linkages of these inputs to common higher-level inputs.
Risk mapping is done to prioritize risk according to frequency of risk, severity of risk or both. Risks in an enterprise can be monitored using risk dashboards, which is a graphical interface to represent the risks in an organization against their tolerance levels. Some of the measures required for the risk management can be financial, human resources, marketing, underwriting, sales/distribution, investments, claims and other external data.
Conclusion
Thus, ERM is a properly structured and disciplined approach to managing risks. ERM aligns the strategies, processes, technologies and knowledge of an organization in order to ameliorate its ability to manage the uncertainties it faces. An enterprise wide risk management capability increases the risk sensitivity of the organization and decreases its functional barriers. Thus, ERM enhances the value of the organization as a whole.
