Commonly any temporary endeavor with a defined beginning and end that is undertaken to meet a specific goal or objective can be considered a project. However, in some special cases that specific definition for a project is much too broad and may not allow for very effective or efficient management of multiple projects.
Think about tying your shoe. According to the definition above, this could in fact be considered a project. Technically it has a defined beginning and end with an end goal in mind. Do you feel as though you require planning meetings and project documents to tie your shoe? Probably not (no pun intended).
Now let’s say you work for the largest shoe manufacturing company in the world and you’ve been asked to convert the company’s whole line of shoes from laces to Velcro. You’re likely speaking of a project that now requires a great deal of time, money, and resources. These changes will likely lead to re-engineering of the shoe designs, new manufacturing equipment being needed, a new marketing strategy required, and the cancellation of your poor shoelace vendor. With so many moving parts, you would be crazy not to have a plan in place before starting, let alone trying to make this transition from laces to Velcro as smooth as possible.
As you can see in the two examples above, the definition of what a “project” is can vary widely. Therefore, our company has decided on our own definition of what we consider a project. This in turn led to the creation of what we call an “operational deliverable”, which in essence is just a smaller project with less moving parts (and often less documentation required). Identifying all new initiatives as being either a project or operational deliverable will allow us to manage our time and resources more efficiently and set standards more appropriately. You can see our definitions below:
Project:
A project is a substantial undertaking that requires full time attention, detailed estimating and planning, regular reporting and a skilled team. A project drives the success of the company
Operational Deliverable:
An operational deliverable is lighter-weight committee work that requires diligence and forethought but has a lower level of formality which does not require heavy-weight paperwork or a dedicated Project Manager. An operational deliverable commonly drives the success of the department or departments
The goal of this blog is to share knowledge pertaining to project management. Many of the blog posts will be educational for those with little to no project management experience, while at the same time insightful enough for those with years of project management experience to still learn a little something. These posts may contain anything from tips, tricks, definitions, demystifications, inspirations, and even explanations. The blog posts are geared towards all those who want to know more about project management both as a methodology and a philosophy.
What is a blog though?
By definition a blog is a website that allows users to share opinions and discuss various topics in the form of an online journal while readers may comment on posts. A blog differentiates itself from a website in a number of ways. Content for blogs is published in a chronological fashion, content is updated regularly, and readers have the opportunity to leave comments.
Where did blogs come from?
The term blog is slang for its original term “web log”. Blogs originated as online diaries in the early 1990’s, and as they evolved, interactive features were added to create more of a two-way conversation. Eventually readers took advantage of hosted blog tools and new features that allowed them to leave comments on blog posts or link to posts on other blogs and websites. As the internet became more social blogs became more popular, and by 2004 the role of blogs became increasingly mainstream. In recent years blogs have become more than online diaries, rather blogging has become an important part of the online and offline worlds, having a greater impact on the worlds of politics, business and society.
Why have a blog?
These days there are dozens of different types of blogs; personal blogs, media blogs, genre blogs, and even photo blogs, however in our case the plan for this blog is to be more of a corporate or organizational blog. In this instance we hope to enhance the internal communication and culture of our company through informative, insightful, educational, and engaging blog posts which we encourage everyone to participate in by leaving their comments and by having discussions.
When will we post to the blog?
Blog writing can be very organic in nature and as such there is no set posting schedule. At this time our plan is to upload new and engaging posts at least on a weekly basis or more, however there may be some weeks that go without new content. We encourage you to check back regularly and to participate in the blog by leaving your thoughts or by having conversations by way of leaving comments below each new post. The more feedback we receive and the more comments and conversations that occur, the more likely we are to upload new posts more often.
Who is behind the blog?
The team behind the blog is TheSmallMoose a Project Facilitator and HoneyBadgerCatcher a Senior Consultant in Project Management.
Ask someone what project management is and you’re likely to get a few blank stares. It’s one of those fields people have heard of, but probably have problems pinning down a definition. Often people think of projects as being for large companies with big budgets, however that’s not necessarily the case. A project could be as simple as improving your golf game.
For example, say you want to improve your golf game by 10 strokes by the end of the season, what do you do? I would hope you don’t just stand there and pray that you magically get better (although I know some people who do that), rather you probably brainstorm or even research different ways that might help to cut out those strokes.
After dedicating an entire lunch hour to researching how fellow golfers improve their game, you work out that $1500 may allow you to do the following:
After negotiating/begging your wife (or husband) and convincing them that $1500 to advance your golf game will improve your emotional health, overall fitness, and even your job prospects, you get to work.
The first step you take is buying yourself that shiny new set of NASA approved, Bluetooth enabled, rocket powered golf clubs, however you ended up spending $1200 of your budget. Your Sherlock Holmesian detective skills allow you to deduce that the remaining $300 is not enough to cover golf lessons for the entire summer... now what?
After working through the details you find that if you take golf lessons every second week and replace that with an additional trip to the driving range each week (which is in the budget), it will accomplish the same goal.
After spending the summer forcing yourself to follow the plan, you find that by the end you have succeeded in accomplishing your goal by reducing your golf score by 10 strokes.
In this very simple example you have planned out what you needed to do, organized how you were going to do it, and even managed the resources you had in order to achieve your goal. In reality project management is no different as it is simply the discipline of planning, organizing, managing, leading, and controlling resources to achieve specific goals. In other words, it’s how one takes an idea from conception through to realization in the most efficient and effective manner using the tools and resources that have been provided or are available. The only difference when we speak of project management in the business sense is that it’s just much more formalized.
If you've ever been in a management or leadership role on a project (and yes, there is a distinction between management and leadership), I'm sure this list will resonate with you. This is a compilation of published data, collated by Derry Simmel, a North Carolina project manager.
These are the 10 most common Lessons Learned by enterprise project teams, as reported and published by their PM Offices.
1. The people we had were great; there just weren’t enough of them.
2. We left management and planning unattended for too long.
3. Unclear roles and responsibilities led to confusion and loss of precious time.
4. We had the most success when we were all informed.
5. Once engaged and informed, management responded quickly and helpfully.
6. We did things right, wrong, and mostly late.
7. We were slowed by constant competition for resources.
8. A great customer relationship got us through many challenges
9. We often did not have the tools and skills needed to do the best job.
10. We did not have a clear understanding of the work when we estimated.
These 10 lessons are bound to resonate with those of you who have been on a substantial project. It's interesting that these pitfalls are so universal in the world of business projects.
More reading on PMO Lessons Learned: Derry Simmel is a fellow PMP from South Carolina. He works with the PM Institute SIG on PM Offices. Derry's work can be found here.
There are many different formats and purposes for a project management office. One size definitely does NOT fit all. For a very projectized and industrial contractor, having a command-and-control PMO makes sense. An industrial PM office takes full ownership of the projects, and handles all resourcing and team organization from a central location. When projects are large standalone microcosms of business, a command-and-control PMO is ideal.
Conversely, in a highly functional environment, like a banking institution or a school district, it makes more sense to decentralize project authority down to the departments. The projects are not part of their core services, and the projects themselves are commonly functional endeavours within a department. In this case, a support-and-enable type of PMO is the way to go.
At our company, we are a health benefits service provider...
where our core service does not revolve around projects. Internal projects are commonly owned by individual departments, sponsored by executive, and staffed by part-time functional resources. Our internal projects are numerous, but commonly under 1000 effort hours each. Coordination across projects and support for the part-time project coordinators and teams are the real need.
After much analysis and deliberation, our company chose to go with a PM office that acts as in a supporting role: enabling staff, coordinating across departments, and providing meaningful decision support for executive and management.
We looked at CMMI and PMI as potential models for our PMO. After close examination, we felt that the P3O/P3M3 model of the UK was the best fit for our services organization.
P3SO is the acronym for Projects/Portfolios/Programs Support Office. If you're interested in the white paper, you can download it here from the UK.
Patrick Lencioni is a consultant with some sage thoughts on group performance. Patrick suggests that there are 5 dysfunctions that are common to project teams and sports clubs:
Absence of Trust.
Fear of Conflict.
Lack of Commitment.
Avoidance of Accountability.
Inattentiveness to Results.
Sound familiar? Join us after the cut for an explanation of this list...
Lencioni's first notion of dysfunction is Absence of Trust. As he describes it, Absence of Trust is where individuals fear being vulnerable within the group...people do not want to show weakness, confess lack of knowledge, admit responsibility for a mistake, or openly ask for help. Commonly, this fear is due in part to low self-confidence. More often, though, this fear is closely tied to low faith in the safety of the environment. And yes: this lack of safety is a direct failure of leadership.
Secondly, Fear of Conflict is Lencioni's descriptor where teams seek artificial (superficial) harmony over meaningful debate. Fear of Conflict stems from a perception that it is unsafe in the team to have differing opinions. Intimidation, reprisal, alpha members devaluing others publicly... these are some of the symptoms of a group that frightens people into tense silence instead of promoting meaningful and honest debate.
Thirdly, Lencioni describes Lack of Commitment as the third common team dysfunction. People will outwardly seem to buy into group decisions, but their engagement is feigned, and they unconsciously seek to do the minimal possible work because of fear, disinterest, or a hopeless sense that their will not be recognized.
Fourthly, Avoidance of Accountability: this dysfunction is a corollary of Lack of Commitment, as it describes people purposely shirking personal responsibility, and purposely allowing mediocrity to continue around them unchallenged and unquestioned. This Avoidance of Accountability is a type of viral despair, transmitted person-to-person by laziness and fear. Unless a charismatic leader steps up to model accountable behaviour, this avoidance behaviour will fester as a team standard of expectation.
Fifthly, Lencioni describes Inattentiveness to Results as being the fifth and most dangerous dysfunction of a team. Inattentiveness describes when individuals become preoccupied with personal success, recognition, status within the team, satisfaction of their own ego, and power-tripping. In each of these neurotic cases, the individual is on a personal agenda and elevates himself over the team, the customer, and the project.
Read more about Patrick Lencioni's consulting work here.
So: what is a leader to do about these problems? Well, friends, that's a big discussion for a separate blog post. But if you'd like to share your experiences, do tell if you've experienced these dysfunctions before. Share your thoughts in the comments below.
The Danger of Reactive Communications as a Management Approach
Reactive communications is the opposite of transparency; it is when management withholds information until every possible detail is known, and the event itself has finally occurred. The employees are not informed before the event, nor are they engaged as part of the input and analysis process.
Reactive communications is usually impersonal, crafted, spun, and often written or recorded as opposed to spoken face-to-face. Most of all: reactive communications are delivered well after employees have the chance to provide input. Business authors Jo Ann Sweeney and Roger D'Aprix explain more about reactive communications, and how it is becoming a tragic trend of distrust in modern corporations...
Jo Ann Sweeney on how Reactive Communications works: http://www.commsabilities.com/blog.asp?blogid=130
Roger D'Aprix and his Communicating for Change book: http://www.sweeneycomms.com/Communicating-for-Change-g.asp
Have you ever been to a meeting where you left afterwards thinking “That was a waste of time”? You may not be able avoid being invited to these meetings, however you can definitely steer clear of holding these meetings yourself...but how?
1. Create an agenda and circulate it ahead of time
Results:
• Communicates the purpose of the meeting
• Allows participants to prepare for the meeting which may lead to more focused and productive discussions
• Allows time boxing of certain topics preventing too much sidetracked conversations
• Communicates any pre-work that attendees may need to complete
2. Ensure the time is well spent
Before calling a meeting, identifying the purpose and the anticipated outcome may allow you to recognize whether holding a meeting is the best way to achieve the result. Think of three different types of meetings:
Information Dissemination
• Purpose: to provide information more personally to individuals or groups
• Result: distribution of information more accurately than by email
Brainstorming
• Purpose: to gather ideas
• Result: enough ideas gathered to proceed forward with decision making
Decision Making
• Purpose: to achieve consensus on a particular topic
• Result: the creation of a list of action items
3. Start, finish, frequency, and follow up
What’s the first thought that pops into your mind when someone books you for a 3 hour meeting? What are you thinking when the meeting starts late then goes over the finish time? I’m sure there are a couple expletives running through your mind when both of these things happen to you. So how do you prevent people from thinking this about your meetings?
One good way to avoid the grunts and groans from the team is to ensure that your meetings always start and finish on time and that you’ve booked the appropriate amount of time required for the meeting. If needed, schedule a follow up meeting rather than continuing on after the scheduled finish time.
Is it a recurring meeting? Don’t just schedule it around your calendar; ask the team what works for them.
4. The secret of note taking
Your meeting ran well but how do you really impress them? Send out a quick meeting recap or meeting minutes. This also helps documenting any important decisions that may have been made and can then be communicated post meeting to all stakeholders (like the boss). This is especially useful for recurring meetings as you can identify repeat issues. Once back at your desk take 5 minutes to clean up and send out the notes to all the participants and really blow their socks off.
5. Repeat action items before adjurning
I can’t stress enough how important it is to review the tasks and responsibilities before adjourning the meeting. Ensure that everyone involved knows exactly what needs to be accomplished and who is responsible to complete each task. This allows you to create a list of action items which can be used to ensure the team stays on track while creating a sense of accountability. Don’t forget to give the action items a deadline so delays can be identified and acted on. Make sure the action item list is included in the meeting minutes which you send out shortly after the conclusion of the meeting.
6. Solicit feedback
Following the 5 criteria outlined previously should prevent a good majority of unproductive meetings; however what does your team think? Ask the team to provide feedback so that you can continue to improve on the next meetings and find something that suits yourself and the team dynamic.
The Common Sense Approach to Simple Project Schedules
You’ve been tasked with creating a schedule for your project or operational deliverable but not quite sure where to start. Thankfully using common sense makes scheduling fairly straight forward and simple. Don’t be fooled however, the larger and more complex projects become the more intense and intricate schedules can become and can often have dedicated resources assigned to manage them. This is only a high level overview of how to schedule a project.
Step 1: Define all the activities
First of all you will need to identify all the tasks that are required to complete the product. Often this list may be found in the Project Charter (usually as components of the Work Breakdown Structure) that may be in progress or if you’re lucky...complete. Alternately the Project Charter may use the list you create, which may mean that you will need to set up a requirement gathering meeting to get a comprehensive list.
Example Result:
Activity #1 Task Alpha
Activity #2 Task Bravo
Activity #3 Task Charlie
Activity #4 Task Delta
Activity #5 Task Echo
Step 2: Sequence the Activities
Now that you have all the activities documented, the next step is to put them in order. During this step you will need to identify any dependencies. A dependency means that a task may not begin or end until other tasks have been started or completed. For example, you cannot install a new window until you have removed the old window. In the example below you will see that the Bravo and Delta tasks may begin after Alpha has completed, but Charlie will need to wait until Bravo is completed, and Echo will need to wait until all the tasks have been completed.
Example:
Step 3: Estimate the Activities resources
This step requires you to identify the resources available for your project. Take into consideration that many of the resources will not be able to dedicate 100% of their time to the project. Assign the resources appropriately to the tasks that match with the resources skills.
Example:
Step 4: Estimate the Activity Durations
Now that all the resources have been assigned, the next step is to estimate how long each task will take to complete. If possible try to use historical data.
Example:
Step 5: Analyse the Schedule
The last step in developing a schedule is to analyze that the sequences, durations, and resources make sense. Often this is the point where you may run into scheduling conflicts and find that you need to reallocate resources or adjust durations of activities. The goal is to ensure that the schedule reflects the planned work. You should also take this time to ensure that the schedule is realistic and achievable. One other good idea is to double check the resource allocations and ensure that they are not over tasked.
The last step is to work with your manager to review the schedule, obtain feedback and then adjust accordingly. Once you have completed the schedule, ensure that you save a duplicate copy somewhere that can be used for historical purposes on future projects. It will also allow you to review your estimates once the project has been completed and capture some lessons learned.
The examples above are only for visual representation as there are much better scheduling software available.
As a project manager I always try and keep things simple. Often I worked with project stakeholders that had never been exposed to project management. Detailed project schedules that I may have created for myself were simply to complicated or cumbersome for others to use. Creating a simplified version of the schedule for the project stakeholders and a slightly more detailed schedule for the project team allowed them to quickly extract the detailed information they required for thier work.
Trying to avoid showcasing all my work was difficult, especially when I was using a new and exciting tool. However, observing what was going on around me allowed me to identify what would work best for the team.
The Best Ways to be the Worst Project Manager (part 1)
1. Planning is for suckers
2. Keep all project information in your head
3. Issues disappear if you ignore them
4. Force the team to respect your authority
5. Blame the messenger
1 – Planning is for suckers.
Why plan? Only the project managers that care about long term success would take the time to plan. Nobody actually needs to ensure that your goals are on track let alone keep the team task oriented. Planning also helps avoid significant issues from arising and prepares you and the team how to handle them; where’s the fun in that if you’re not running around like a chicken with its head cut off? Just saying.
2 – Keep all project information in your head
Nobody likes taking notes during meetings, so why should you? If you make any formal decisions, just make an agreement with the other people in the room that at least one of you will remember it later on when the boss asks. Plus your team should be able to read your mind by this point so it’s not like you need to communicate any of these decisions to them anyways. Plus they can’t fire you if you are the only one that knows what’s going on...right?
3 – Issues disappear if you ignore them
There are always issues on projects but if you leave them long enough eventually somebody else will fix them, or they won’t be issues anymore. This is especially true if they are complex issues, nobody has time to deal with those anyways. Just make sure not to document them anywhere which might let someone track it back to you and blame you for it.
4 – Force the team to respect your authority
Make sure that you make the team work harder and longer than you do so they know who the boss is. They will respect you because you are an authority figure, not because you do good work. Setting super high unachievable goals for the team will make you look really good in front of the boss, and when you don’t achieve those goals, blame it on the team and prepare yourself for a promotion.
5 – Blame the messenger
Whenever a team member comes to give you bad news about something that’s gone wrong reprimand them immediately, even if it’s not their fault. If the rest of the team knows how mad you can get when small things go wrong they will be more motivated to fix it and ensure nothing else goes wrong in the future. Going forward if things do go wrong the team won’t tell you about them...out of sight out of mind right? Also, close your office door just in case those who didn’t get the message earlier feel as though they can still come talk to you.
Culture is about attitudes, expectations, and relationships in a human ecosystem. Culture, at its core, is really about human inertia, something that you cannot directly control, but if you're good, you can influence its direction.
I'm thinking of a personal example when I was managing a recreational dragon boat paddling team some years back. Some of the core members were interested in moving to a higher level of performance, but felt that most of the crew was interested in beer-league level of play. After much discussion, the informal leaders within the crew decided that we should implement performance metrics, and actually use scientific measures on the ergometer and time trials on the individual outrigger hulls.
Well, the culture of the group, which had formed over the course of two seasons, was very resistant...
In fact, despite the leadership clout of the three core members, the majority of the paddling crew actively resisted the idea of being measured like Olympic athletes. Let me fast-track the rest of the story: that recreational team ending up churning nearly 70% of its membership. The disgruntled majority formed a separate dragon boat crew that trained for a recreational mandate that preserved the original desires and comfort level of the team. The remaining competitive-minded paddlers (a small minority) had to build their competitive concept into a self-sponsored program, starting from scratch.
Human intertia, allowed to go in its two separate directions in this case...
1) 2011: The recreational crew is happily enjoying their cultural objective and their recreational performance.
2) 2011: The competitive crew ended up attracting and training a total of 40 competitive athletes. After multiple seasons of training, they went on to represent Canada at the Macau and Malaysia World Championships in 2010.
So: what can be concluded from this substantial team churn and culture-shifting? Well, I would suggest that any significant organizational change requires that the human relationships, attitudes, and expectations be meaningfully addressed as part of that change. And if the change is a significant shift, then you need to plan for a big churn and turnover of the individuals who subconsciously steward the old attitudes and relationships you are trying to move away from.
Human intertia ("culture") really does eat strategy for breakfast. Make sure that your change management plans acknowledge this.
When people ask you how work is, do you reflexively respond 'work is busy'? While you likely have many outstanding tasks on your plate and projects that need your diligent attention, ask yourself these two questions:
1) Is 'being busy' part of your self identity?
2) Does 'being busy' mean that you are also productive?
Paul Andrew, a blogger with theLeadershipCoach.com, suggests that if being busy = part of your self concept, then something is amiss.
According to Paul Andrew, busy-ness is an insidious drug that deludes us into skewing our personal value systems.
Dr. Stephen Covey resists this busy-ness compulsion, and suggests that we take a breather and evaluate every aspect of our day... deliberately decide for yourself how each activity ranks for urgency and importance.
This urgency-importance distinction might seem pedantic, but I would suggest that it is a life-changing approach to one's job. The notion of urgent-vs.-important is critical for those of you who have autonomy and authority in your role. If you hold a self-directed position where you can dictate how you spend your work time, then I suggest that the urgent-vs.-important measuring stick is a crucial mental tool for deciding how you allot your 40 hrs this week.
Ironically, urgent-vs.-important is even more critical when you don't have autonomous control over your daily work. If you are in a support/assistant role, or if your work is very interrupt-driven by nature, then being aware of urgency and criticality empowers you in two areas:
You are in a unique position to provide guiding feedback to your supervisor and customers over what is worthy of prioritized time
You are in a position to evaluate the value of your current role in the company
I have to stop myself here before I launch into a manifesto of what purposeful and meaningful work is. Instead, let me link you to Paul Andrew's blog post, where you can submit your comments on the addictive and lying drug of 'being busy'. Indeed, being busy does NOT equate to being productive. Running a treadmill each day does not mean you are adding meaningful value to the organization, and the intelligent worker knows this.
pixelskylines
baratheonpilled
yousharknotpass
jacobvanloon
jbbartram-illu
stormborns
annaxmalina