-
We had a recent webinar about the work breakdown structure (WBS) and the size of project activities that should be included in your project management software. As part of that, we acknowledged that your existing software will allow the team to create an activity list that has a very small duration, e.g. one day, one hour, one minute. My questions: Are there advantages to include very small duration activities in the project plan? Does a small duration activity really improve the team’s ability to track and monitor project progress? Are there disadvantages to including small duration activities in the project plan?
There have been many cases where a large project is decomposed into very small activities. One advantage of doing this is that all work to be accomplished can be identified. It’s less likely you will forget anything. Critical activities can be highlighted using various project management software tools. Activities can be assigned to one team member and there is no confusion as to who has responsibility for it. The team sees a lot of progress when many activities are reported complete.
As we rambled through our webinar, it occurred to me that one of the disadvantages of very small duration activities is that it discourages active project planning. Because so much detail is expected, it seems like a hopeless waste of time, especially when there’s work to be done! It’s difficult enough to get team members to spend time planning, and to get project sponsors and management to allow time for planning. By creating micro-activities, teams spend time decomposing the WBS when they could be focused on other planning activities, such as identifying and evaluating risk. In addition, small duration activities encourage micromanagement. It would be better for most teams if the project manager would just get out of the way and let the individuals assigned do their work. Also, a larger activity allows the team to include work that may come from different team members, departments, functional groups, etc. It leads to better integration of different components of the project. If teams define their activities in 40 – 80 hour increments, they can easily measure project progress at each team meeting. It’s not necessary to have all the detail reported in the project management software as long as the scope and deliverables of the activity are well defined. And that’s a topic for another time!
|
-
Most of us know that project managers have to wear many hats. They are a communicator, a counselor, a drill sergeant, a negotiator and even an accountant at times. But did you ever consider the project manager and their role as a sales person?
If you agree with the concept that businesses ONLY grow through implementing projects to augment and expand on their on-going operations, then you realize that projects are very much tied to revenue growth of organizations.
Now consider an organization that generates its revenues based on delivering products to customers through projects. A consulting organization, a technology product that requires implementation efforts and a new product that requires the modification of business processes are all examples of projects that GENERATE revenue directly and allow organizations to grow.
In these organizations, the sales team(s) make the initial contact with the customer, sell them on the products and services that are offered, close the sale and then hand the implementation of that sale over to the project manager. Now the project manager has control and the sales team takes a back seat.
As project managers we learn the importance of defining scope early on in the project well enough so that if any questions are raised later in the project, that it would be obvious as to whether or not the change requested is truly in scope. We learn also that it is the project manager’s responsibility to NOT make changes that are not in scope and that a strong change control process needs to be in place to determine the appropriate distribution of a change. Changes typically are categorized in one of these three categories:
- Changes necessary to support the objectives of the project
- Changes that are optional and the customer is willing to pay for the change in scope
- Changes that are nice to have and truly out of scope
What we haven’t really addressed in the literature to date is the IMPORTANCE of the project manager’s role in managing those that are the “nice to haves”.
Project managers who have a keen sense of how their organization raises revenues can add significant value to an organization by managing even the changes that aren’t approved. I call the project manager that manages these well the sales person’s best friend. These ideas came directly from the project manager’s ability to manage requirements and scope well. They are items that a customer has asked for but was willing to wait for delivery or address at a different time. They are items that in the hands of the sales team, can grow into on-going work and a stronger relationship with the client. In my experience, customers who know that their vendor is managing their projects to the agreed upon scope and is monitoring and keeping a keen eye their specific needs will build a consultative relationship with their vendor.
The first key step is to ensure that the scope and requirements are well thought out so that when requests are presented there is little or no disagreement as to the inclusion of scope or not. This eliminates any contention or disagreement within the change control process. The next step is to have a system for maintaining the items that were not included where there is an interest by the client to implement at a later date.The final step is for the project manager to have an open communication channel to the sales team. Sales persons generally do not like to walk into a client without something to offer. You, as the project manager, can provide a steady stream of “reasons” to engage with your customers. To succeed in this kind of environment the project manager must think like a sales person and take the time and effort to reach out to the sales team and provide them insight as to the progress of the project an any new opportunities that may exist.
|
-
The project charter has been around for as long as the concept of work.
The Egyptians used project charters to create the Pyramids. So did the Greeks to erect the Parthenon. Even the Romans used a project charter to create the Coliseum. Little Johnny used a project charter to construct his miniature house made of Lego blocks.
As different as the times and methods used to create these structures, one common thread exists - success was based on the creation, maintenance and oversight of a project charter. The Egyptians may have created theirs with hieroglyphics in the sand, the Greeks may have chiseled theirs in Mount Olympus, the Romans may have penned theirs in Latin and little Johnny may have used Crayola on the kitchen table. The point is not how complex or sophisticated these project charters were, but rather, that one was required, prepared and relied upon to act as the cornerstone to creating all of these structures.
While academia can spend days crafting a definition of the complexities and internal dynamics of a project charter, anyone can understand it using six simple words: "what are we trying to do?"
Though the term project charter is routinely applied and recognized within the Information Technology (IT) industry, the concept of project charter is as applicable to organizational strategic planning, corporate budgeting and operational oversight. It is difficult to fathom a corporate president or CEO performing their roles without defining and documenting "what are we trying to do?" or a CFO maintaining fiscal control without defining and documenting "what are we trying to do?". The question of "what are we trying to do?" permeates every facet of every organization. Suffice it to say, the tenure of a CEO would not be very long if they were unable to articulate and gain approval of "what are we trying to do?" from the shareholders.
On the surface, addressing the project charter "what are we trying to do?" question appears to be a simple exercise, be it a CEO, CFO or an IT Project Manager. In reality, it can become a very trying and taxing exercise. The amount of definition and explanation required in a project charter depends upon the magnitude and complexity of the "what are we trying to do?" question. A project charter used to document how one person should dig a hole in the ground could be documented on half a sheet of paper, while a project charter used to document how to send a space craft to the moon and back would probably require volumes of detail.
The utilization of a project charter is as varied as the number of organizations that create and apply them. In some cases the project charter is the project's bible and is relied upon throughout the project. In others cases, the project charter is a project title and a brief project description. The project charter has been adapted and customized by organizations to address a myriad of needs. Here are a few contexts where the project charter is used.
Corporate - Project Definition As an initial project document, the project charter establishes the goal posts from which the project will be initiated, planned, pursued and completed. The project's definition will reflect its size and complexity. It can include the following:
- The purpose of the project
- The scope
- The objectives
- The resources (HR and otherwise) to be utilized on the project
- The plan
- The constraints
- The quality
- The cost estimate
- Project hierarchy and organization
- Risks and impacts the project will have on the organization.
The project charter is not a stagnant document; it evolves and is maintained to reflect the changing circumstances and conditions associated with the project. The project charter acts to establish the project context and boundaries to ensure all project team stakeholders and resources have a common point of reference and communication of the project throughout its duration.
Corporate - Project Authorization
The project charter gives organizational stakeholders the ability to review and evaluate priorities. Utilizing the project charter to obtain formal authorization ensures there is a correlation between the corporate strategy, planning and budgeting exercises and the organizational resources allocated to complete a project. This ensures organizational resources will remained focused on the authorized projects.
Corporate - Project Scope Management
After establishing the project context and boundaries, and receiving formal authorization, the project charter can be used to monitor and evaluate the scope of the project from beginning to end. Project stakeholders are able to reference the project charter to monitor the project progress and direction in relation to the original context and boundaries they had originally approved. This affords project stakeholders the flexibility to stop, defer or accelerate IT project team priorities to better reflect organizational business needs. It also enables IT project team resources the ability to re-calibrate their efforts based on decisions and approvals of organizational stakeholders.
Corporate - Formal Deliverable
The project charter establishes an operational premise to promote structure and formal documentation. This is very important to the efficiency of IT delivery and support. This concept of structure and documentation can be leveraged by the organization to introduce quality assurance and to improve the maintenance and support of applications.
Project - Planning & Oversight Benchmark
Once authorized, the project charter can act as the basis for a project planning exercise. The Project Manager is able to reference the original definitions established and authorized in the project charter to provide greater clarity and detail on how the project will be executed. Project plans, project schedules, project resources and project budget allocations are derived from the authorized project charter.
Project - Team Communication
The authorized project charter provides the mechanism the project team will rely on throughout the life of the project. It acts as the basis for the deliverables and work products identified in the project plan and project schedule. Having formal documentation prepared provides several benefits. Project development teams will have access to the necessary information to ensure project team communication is consistent and based on formal approvals - all project development team members can rely on the authorized deliverables to ensure they are working off the same page. Application support and maintenance teams have a common point of reference they can leverage to effectively maintain and incorporate new functionality into the applications.
Wrap Up Although the concept and need to create a project charter has meant different things in different environments for different audiences, its primary purpose has remained the same. Be it the Egyptians or Little Johnny, as long as the concept of work exists, success will be dependent on our ability to understand the question of "what are we trying to do?". A project charter helps us to answer that question.
|
-
The ancient Greeks first coined the term "methodos" - its definition meaning "path." They applied this term in various contexts - as a noun "a path that could be followed to reach a destination" and a verb "the journey to be taken along a path." Though several millennia have passed since the ancient Greeks first used the term, it is still applicable in today's world of Information Technology (IT) – it is called "IT Methodology".
As simple as the term IT Methodology may appear, it is intriguing to see how it can be applied in such a variety of contexts, by such a wide array of experts, to such a diversified set of audiences - it can be applied to project management, software development, and software testing lifecycles. Suffice it to say, this lack of clarity and context has introduced its own share of confusion, misunderstanding, miscommunication and misadventure.
Let’s provide a context around the term "IT Methodology"
IT Methodology – the road you take
As a noun, "methodos" can be equated to a road on a map. For example, the highway that connects Boston to New York, it has a beginning and an end. It is tangible. It has a predefined set of destinations that must be passed along the way, such as a city, a town, a river, a crossroads, etc. The road is constant and indifferent to how many vehicles use it, what vehicle is to be used, how many people are in each vehicle, how fast each vehicle travels or how many times the vehicle starts and stops during its journey.
As a noun, "IT methodology" is much the same as the road. It has a beginning and an end. It has a pre-defined set of criteria that must be passed along the way: lifecycles, phases, deliverables, work products, etc. It is consistent and indifferent to how many projects utilize it, the scope of each of the projects, the size of the project team, the speed at which a project team completes it, the number of iterations a project team employs. Examples include ITIL, Rational Unified Process (RUP), CoBit, and QAIassist Integrated Methodology.
IT Methodology - how you travel that road
As a verb, "methodos" describes how the road will be used. Travelers using the road between Boston and New York have the option to travel in the vehicle of their choice at the speed they wish, and to make as many stops as they wish along the way.
As a verb, "IT Methodology" is the delivery approach a project team takes to get to its destination, a completed project. Examples of delivery approaches include Waterfall, Spiral, Rapid Application Development (RAD), Agile, Joint Application Development (JAD), and Scrum.
IT’s not all Greek
Though the effort to understand the term "IT methodology" may appear to be long, winding and Greek to many, there is a difference between the “road” used to get to the destination and the “activities” that will be performed while on the road and heading to the destination.While most people will agree that it’s important to agree on the goal of a project, we tend to forget that agreeing on how we will achieve that goal is just as important.
|
-
While most of the time, I try to keep my posts project management solution agnostic, we've had some new ideas here about making our process here at Project Insight better which I will share with you here.
We have 40 unique live training webinars that we offer to our customers. We also record these sessions so that our team members in far flung corners of the globe (we serve project teams in Papua New Guinea, Japan, India and other locations that are asleep while we conduct live webinars) can watch them later. We have developed best practices modules that are like courseware. Alongside these training resources, we have other self serve resources like tutorials inside the software, online help, tool tips, FAQs in the Community, and more.
With all these resources on hand, we are now encouraging customers to select the webinars that are right for them. Select the project team members that should attend each webinar, breaking the team down into the following groups (at a minimum):
-Administrators
-Project managers
-Project schedulers
-Resource managers -Team members
-Executives
You can even break the groups down into business units, departments, and/or process groups. Once that is done, select one webinar to watch as a group. Follow that up by performing the best practice module on the same topic. Then gather as a group and decide how your project team will use the software.
Once you have outlined the best practices for your specific organization. DOCUMENT those processes. This documentation may be as detailed as you wish. From those documents, develop one to two page 'Quick Start Guides' for each group listed above. That way, if new team members join the organization, they may refer to these Quick Start Guides that are particular to your organization and specific to their role. Feel free to add comments!
|
-
I’m always talking about having three elements in your project management software implementation: people, product and processes. In order for your implementation to be successful, you need all three. Within each element, there are many segments, variables. I’d like you to make sure you have thought of the following:
Product – Project Management Software -Make sure that you are actually looking for project management software, and not task management software, or time tracking tools, or a help desk. Be clear on the business challenges you are trying to solve, then make sure you are looking at the right TYPE of solution.
-Make sure that the project management solution provider is mature and well-proven in use at other organizations with requirements similar to your organization. Many software companies are popping up and may not have the track record to serve you well. -Make sure you select a flexible, customizable and USABLE project software solution. If the system is flexible it will serve your needs now and in the future. If it is integrate-able, then you can pass data from one application to another eliminating duplicate effort. -Make sure there are no major GAPs with respect to your needs and requirements. Make sure the vendors do not try to steer you in a direction that is not a part of your goals. You would be surprised how many people get distracted by the ‘shiny object’ or feature that looks sexy, but has no relevance to their needs. -Make sure you have enough resources to actually implement the portfolio and project management software you select. -Make sure you select a product built on an industry standard platform. Project management products built with graphic artist platform tools are often lacking when it comes to robust scheduling and resource management.
Process or Business Processes -Make sure you understand your current business process and which parts of the process you will maintain and which ones you will ‘throw out the window.’ Not all processes are efficicient, but some are. Keep those in place. -Make sure you start to document your processes, even if it is a simple bullet list. You have to start somewhere! -Make sure the project solution you pick is flexible enough to support your proven business processes. Do not worry about the inefficient or broken processes!
People – Leadership! -Make sure you understand that any software you change to involves CHANGE. Change is easy for some, more difficult for others. Be prepared for all responses. -Make sure you have a communication plan in place to handle hiccups in your implementation. Nothing is perfect, so acknowledge that, but also plan for how you will handle issues as they arise. -Make sure your leadership is on board. Nothing is more frustrating than investing in a new system and then not having the management help with the leadership and communication plan. Thoughts? Feel free to post agreements, disagreements?
|
-
In an earlier blog post, I mentioned needing three mission critical elements to a successful roll out: people, product and processes. Similar to only having two legs on a stool, if you need all three for a successful implementation. This week, I talked with a customer that had, early on in the implementation process, decided to let people have the option to use our project management software or not. It was going to be their choice. The problem with this is kind of like saying, I'd like you to go on a diet, but it's your choice. As we all know, change is difficult, and for some organizational cultures, it is more challenging than others. I was told by a child psychologist, that if you want your children to change a behavior, it takes 90 days of reinforcing that behavior. If one day, you are lax and slip from the message to your child, you have to start your 90 days all over again. The same is true of adults, I find. Just like children, it takes time to change a behavior. Like children, even grown ups like a system of rewards. You can instill a system of rewards or of punishments, again depending on your culture and what you find works.
One of the most positive systems of rewards I've witnessed of late comes from one customer that decided to all team members profit sharing for accurate and timely time tracking. Now, the point is not about the feature of time tracking, rather it is about the system of rewards for the behavior we desire. This is having a very positive effect on the team and compliance, as you might imagine is very high, as the reward is MONEY! One of the most stringent punishment systems I've witnessed is a customer that expects all expenses to be submitted within one month of incurring them or else the team member does not get reimbursed. Again, hitting the team member in the pocket book is a pretty harsh penalty. When I asked how successful that is, the customer replied that it only happens to a team member once!
The point is that the company's leadership must communicate what behavior is desired, clearly and frequently, as well as develop strategies for compliance or lack thereof. If the message your leadership is sending is 'I don' care one way or the other,' people will do what is easiest for them to do. This is either nothing or the old way. Leadership is key in a successful implementation!
|
-
If you've finished the project template creation process discussed in the last post, then you are ready to start thinking about how your tasks and activities link together. If you have worked with Microsoft Project, then you know about task dependencies. If you are migrating from Excel, then the idea might be new. Basically, tasks have relationships. That is, often one task must be finished before another one can get started. This is called a finish-to-start task type. There are four task types:
1. Finish-to-start 2. Start-to-start3. Finish-to-finish
4. Start-to-finish
If you set up your tasks with dependencies or relationships, then you can leverage what we call 'intelligent scheduling.' This allows a project manager to change the start date of the project and the tasks will automatically shift and correct (assuming you have not used any constraints, but we'll get into that later). The other advantage is that if you change the task duration or timeframe needed to perform the task, then the schedule will shift as well. The 'geeky' definitions of the task dependencies listed above are:
Finish-to-start - The preceding task must finish before the successor task (task following it) can get started
Start-to-start - The preceding task must start before the successor can start, but they can start in parallel
Finish-to-finish - The preceding task must finish before the successor can finish
Start-to-finish - The preceding task must start before the successor can finish A good project template will use these task types so that the projects created from the template will be as flexible as possible. You may link your tasks using drag and drop on our interactive Gantt chart, or you may add predecessors in the task list view. If you are migrating from Microsoft Project, then the easiest method is to add the 'predecessors by number' and 'task number' columns. This allows you to work as you would in Microsoft Project, simply adding the predecessor task number and the same abbreviations in Microsoft Project. For example, 3SS means that task 3 is the predecessor task to the current task and it is a start-to-start relationship type. You may need to sit with your team to determine what the right task flow is, but believe me it's worth the time to get a great project template that is available for continual re-use.
|
-
While every project is unique, many projects of a certain type have repeatable phases and tasks. If this is true for your project team, then it makes sense to sit down and develop your project templates. We recommend getting the people that belong to the team or department or group together for a meeting. We like to perform the 'sticky note' exercise as a method of capturing all activities or tasks on a project. What's this? The team meets and one person acts as the moderator, writing down all individual tasks on a 'sticky note' and putting it on the wall or white board. The team outlines all tasks and activities without judgment about the level of detail or what order the tasks should be in. Just brainstorm and collect all the tasks, one per sticky note.Once you are satisfied that you have outlined all activities that encompass that project type, then you may organize them in an outline or WBS (work breakdown structure) format. The first group of tasks is labeled 1.0 in your WBS. One rule of thumb is that phases or summary tasks should start with words that are nouns, whereas tasks start with verbs because they are things that you 'do.' A lively discussion usually ensues. Be patient and take the time to get the outline right. You are also building team agreement during the process. That is, you want 'buy in' from the project team about the steps that the project will take to complete. By participating in the process, the team members will offer less resistance, as they helped 'build the house,' so to speak.The next step is to look at the level of detail that you have outlined. Sometimes it is appropriate to build out more detail, but in our experience, it is more likely that you will want to trim out some of the detail. This makes your task list or WBS more manageable. More experienced project managers know that the more junior the staff, the more detail you need to have. If your team is experienced, you may still want to have details in the task description fields of your project management software solution. Steps may be outlined there, instead of making the steps individual tasks. This keeps the team members' burden of updating tasks down and you will get more adoption! We had a customer that had task lists initially built out to the 15 minute increment in Project Insight, project management software. That turned out to be too cumbersome for their fast paced environment. Imagine having to check off a task every 15 minutes! So they trimmed down the template and people were much happier. Another customer told me that she was out for surgery last year and because she had built out exact steps in the task description fields, the project manager that took over for her was able to complete the project on schedule without any hiccups. Great success story and wonderful use of project templates. To recap:-Meet with the team-Write down all tasks on sticky notes-Arrange sticky notes into an outline-Decide how much detail you need-Then, put your results into your project software tool!
|
-
Too often people purchase a new project management software solution and want to put their first project in right away, without doing the 'homework' first. Before you enter in any information, be sure to follow your software provider's best practices.
Attend the webinar
The first step with Project Insight is to understand the global settings in the system administration. You may do this by attending one of our webinars. It's an hour well spent! It is very simple to enter data in our software, however, the key is WHAT data or information SHOULD you put in the solution? Once you have attended the webinar, you will have a foundation for doing the homework assignment.
Read the Best Practices
We have developed Best Practices on many subject areas. It is a good idea to read and understand these documents as step two. You will find these resources in our customer Community.
Do your homework
We provide you with an outline of questions that you need to ask yourself and quite possibly the entire team. I won't reiterate the whole list here, but as an example, let's take project types. You will need to populate your global settings with the list of project types that your team performs. In some cases, you may already know what the list is. However, it is also beneficial to ask the project team members, so that your list is complete and thorough, and you don't have to change it later. In our example of project types, this information is tied to the reports and dashboards. So, you will want to ask yourself, how would I, or my management team, like to see this data rolled up? Make sure the terminology is familiar and agreed upon. Do this for each of the global settings.
Input the information
Now that you have an understanding of the functionality, you have read the best practice documents and met with your team, you are ready to input the information. This will lay the foundation for the project managers to input their projects and templates. When they go in to add their projects, all the pull down menus and select lists will be in place to make their jobs easier!
|
-
If your project management software implementation includes asking team members to enter time in the system, then you will want to develop a communication plan to make the effort fun. Again, this top ten list is from one of our culturally young customers that wanted to use the 'carrot ' method to incentivize their team to enter time on a daily basis. Here are the final two reasons they came up with for tracking time in Project Insight:
#2 - Because your granddad punched that time clock on the shop floor every day for 30 years, and you can't click a mouse?
#1 - Because it's the second more fun thing you can do with your right hand.
We hope you had a good laugh over this list. Feel free to add your fun reasons as comments here.
|
-
Like David Letterman's Top Ten list each night, this Project Insight customer surveyed their team as a way to get buy in from all team members. Creating this top ten list was their way of incorporating all team members in the initial effort to get compliance on entering time.
#4 - Better timekeeping promotes profitability which will allow us to donate underwear to major celebrities
#3 - Maybe this will finally end the East coast West coast wars
Wait a couple more days for the final installment......
|
-
As we come up on the Labor Day weekend, a celebration of labor, then why not embrace the concept of entering time. It not only provides you with the big picture of what you actually accomplished during the day, but also provides management with the feedback that you are really working hard! From one of our leading project management customers, here are reasons #6 and #5 for entering your time.
#6 - Every 20th entry gets a coupon for a carwash
#5 - Project Insight time conflicts will be settled by team dance competitions.
Have a great weekend!
|
-
Why is getting white collar workers to enter time so difficult? One reason I believe people resist entering time is because they believe it is something that only blue collar workers should do. For example, we hear 'It's like punching a time clock." Or, 'That's so Big Brother.' Or even, 'I don't want to be micro managed.'
One connection project team members do not always make is that the exercise is less about micro managing them than getting a better picture of how long certain tasks and activities actually take to perform. It is about better project budgeting and estimating for future projects. For project teams that run customer facing projects, it is about making sure that the original quote or bid is correct. If not, then we can make adjustments and learn from our mistakes.
Here are the #8 and #7 'tongue in cheek ' reasons to enter your time in a project management software solution:
#8 - All un-submitted time gets converted to spent vacation days.
#7 - Every time you enter your time, an angel gets his/her wings.
|
-
We had a customer rolling out our project management software to over 400 people, including everyone from the folks that stock their campus cafes to the President and CEO! Naturally, anytime you have a large roll out, you need to constantly communicate what behavior you would like people to perform. One of the 'carrot' programs this customer chose to get folks excited about entering their time was to ask all employees to submit their Top 10 Reasons why they should enter their time in the software. (Like the Top 10 list on Letterman).
Starting at Number 10.....
#10 - Because Oprah recommended it, Trump will fire you if you don't, and Rosie O'Donnell will eat you if you don't!
#9 - So you can keep getting paychecks and not have to move back in with your parents
We'll share those top ten reaons here every couple of days....in hopes that you will post your Top 10 as well.
|
More Posts Next page »
|
|