Office Add.in

What is a "Task" and how long should it be?

Sun, 22 Mar 2009 00:00:00 GMT

The short answer... Tasks are concrete activities that should be between 4 hours and 5 days long.

Why? Tasks or "Schedule Activities" make up the work packages of your WBS and are the lowest level of your schedule. As such tasks should have a defined outcome, an estimated cost, duration and a set of resources required. Each task in your project needs a who, does what to what level and when by.

Why should tasks be "...concrete activities..."?
Tasks need to be described by outcomes so you can judge when they are complete. Each task should have a measurable outcome and the expected level of the outcome. "Create steel framework to hold 2T of weight" is a concrete task. "Create accounting program" isn't, while "upload and verify all 5 million accounting transactions from legacy system" is. Measurable outcomes are required so you know when the task is finished.

Why should tasks be "...between 4 hours and 5 days long"?
At the minimum a task should take 4 hours. Anything less than that isn't a task, it's just an action. Actions like flipping a switch shouldn't be a task. Your schedule isn't there to program your team members like robots. As a PM it's not your job to micro manage your people, it's your job to help them achieve the outcomes of the tasks and thus the project.

At the maximum a task should take 5 days. Longer tasks should be broken down into smaller measurable tasks that are achievable in less than 5 days. Having a maximum is just as important as not micro managing. Any tasks longer than a working week often gets put off until the next week, or the week after. Tasks and their completion on schedule are an important indicator of the health of your project, if your tasks are longer than a week it'll be too late when you find out you are weeks behind in schedule.

To overcome the problem of long tasks, people often use "Percent Complete" to monitor the completeness of a task. The result is often that tasks are 90% done for 200% of the scheduled time. When using this i have often noticed that the last 10% often takes 190% of the scheduled time. Percent Complete isn't a waste of time but should only be used as an indicator for reporting on WBS work packages. It should not be used to monitor tasks. Tasks are either done, or not done.

How do tasks relate to the WBS?
Tasks or using PMBOK terminology: "Schedule Activities" are not part of the Work Breakdown Structure. The WBS should be devolved to distinct Work Packages which each have a distinct deliverable. The WBS stops at the Work Package level or deliverables. Typically these deliverables take several activities to complete, so in the schedule the Work Packages are devolved into discrete activities (or tasks) with outcomes, estimated duration, cost and resources with relationships to other activities in the Work Package. ie: Who does what and to what level and by when.

PM Templates

Sun, 22 Feb 2009 00:00:00 GMT

Project Management is not about the tools you have, but it certainly helps to have some tools. I've posted a series of templates and examples i and others have created for starting, running and closing your projects.

If you have a suggestion for improvement please leave a comment below. I'd also like to hear of my work being used, just send an email to markn at enspace dot com or use the contact page here.

PM Checklist This is a lists of outputs of PM processes. This is useful to track what PM outputs are required on your project.

Project Managment Plan This template forms the basis of the Project Management Plan. PM's must use this and tailor it as required by their sponsor. I've also included a completed example PM Plan.

Business Requirement Statement A BRS would typically be used after project initiation to capture the details in the business requirements that drive our project. Each Requirement should be listed in the Requirement Register. I've included a completed example BRS.

Project Status Report This tool is designed for regular use (weekly) to report the status of your project to the Program Manager. This excellent one page status report was designed by Richard Harris of SMS Consulting and is used with permission.

Team Member Status Report On large projects this tool can be used for team members to communicate their status updates to the PM. The PM then would use this to help complete their Status Report to the PMO and sponsor. This was developed by Peta Greensill and is used with permission.

Project Communique : An example document to be used as a template to communicate to large groups of stakeholders about important events in a project that affect them. This should highlight what the effects of any changes will be, who the will affect and what they can do if something goes wrong. It is a good idea to keep these down to one page and send the document out as a pdf to inhibit changes.

Post Implementation Review A PIR is an important part of closing a project. The information gathered will help generate your Lessons Learned files and become part of your enterprise assets for future projects.

Some tools to come...

Project Initiation Template or Project Charter (to be uploaded)

Example Risk Assessment Process : An example Risk Management Process. (to be uploaded)

Risk Register (to be uploaded)

Issue Register (to be uploaded)

Requirement Register (to be uploaded)

Quality Register (to be uploaded)

Project Budgets (to be uploaded)

This work is licensed under a Creative Commons Attribution 3.0 License. This means you may use it for any purpose, and make any changes you like. I only ask that you include a link back to this page in your credits (contact me to discuss specifics if you are unsure)

Team Members guide to Projects

Sun, 19 Apr 2009 00:00:00 GMT

When working on a project i have often been asked by new team members why is this a "project"? what does that mean to them? and why are we doing thing the way we are doing them? I created this three part guide to cover some of the background and general expectations PM have of their teams.

What is a "project" and what do I do on one? Team responsibilities. Activities you may expect to do on any project. Some terminology. Tasks, Risks and Governance
Tasks Management Completing tasks make up 90% of team members work.* Task Management formula: Who does What to What Level, by When? Task management is extremely important but does not stand alone from governance and risk management.	Risk Management and Good Governance. In addition to completing tasks, some team responsibilities relate to governance Governance activities are there to ensure the tasks are right for the organisation. Other team responsibilities relate to risk management Managing risk minimises harm and maximises opportunities for the organisation.
Guide for new project team members.

* NB: 87.4% of statistics are made up on the spot.

I'm on a project... what now? (Part 3)

Sun, 12 Apr 2009 00:00:00 GMT

Part 3 : Risk Management and Good Governance; ensuring the tasks are right for the business.

NB: You way want to have a look at the first two parts of this post on projects and tasks.

Projects create something unique for your organisation and compared to day to day operations, a lot more things can go wrong. This is where risk management and good governance come in. When working on a project team you will be involved in risk and governance processes to help reduce the uncertainty and ensure the project delivers what was expected for the monies spent. A project without the risk and governance aspects is just a a bunch of people doing tasks and hoping that they deliver what their executives funded.

It is often difficult to work out how much effort should be spent on governance and ideally your organisation has its own appropriate methodologies that define the level of governance required. Typically the level of governance required depends on the risk associated with the project. The higher the risk, the higher the governance needed. Building a bridge wrong has more terrible consequences than building a single house wrong. Erroneous banking computer systems have a lot more impact than errors in maintenance planning software. Risk can also be positive, and similarly the higher the positive risk, the more governance is required. R&D for a new product model may be a fantastic opportunity for an organisation, while choosing a new season's colour for the existing model may not have such an impact, so would require less governance.

Risk is first assessed by the impact of the consequence, then the probability of the consequence. It's typical for organisations to dictate the actions required once the risk has been assessed. Interestingly, appetite for risk varies between industries and organisations.

An example matrix identifying a "Risk Score" by Likelihood (probability) and Consequence (impact)

Based on the risk assessment above, the level of Governance and action is prescribed.

The Project Management Body of Knowledge (PMBOK) 3rd edition details 44 separate project management processes for managing risk and good governance of projects. The use of these 44 processes depends on the project and ideally the effort applied should directly relate to the risk of the project itself and the organisations risk tolerance. These processes are;

Time Estimating, schedule creation and control.	Scope Scope planning and definition, creation of WBS, verification and control of scope.
Quality Quality planning, assurance and control.	Cost Cost estimation, budgeting and cost control.
Communications Planning, information distribution, performance reporting and managing stakeholders.	People HR Planning, acquisition, development and management of project team.
Procurement Plan purchases, contracting from RFQ to contract closure.	Risk Planning, identification of risks, risk analysis, risk response planning and continuous risk control.
Integration Project initiation and planning, project execution and control and finally project close.
Summary of the nine project management areas and 44 processes in the PMBOK standard.

The forty four processes are a way of detailing the work that needs to be done on a project to manage risk and ensure good governance. Most processes such as quality control directly relate to the Task Management responsibilities of team members. Other processes such as "Project Close" aren't directly related to getting things done, however it's extremely important to make sure everyone gets paid and assess the success of the project, so that future projects can learn from the successes and failures of this one.

These good governance processes can be broken down into activities typically expected to be performed with the project team members and Part 1 of this post gives further examples.

A successful project is within budget, scope and schedule constraints and fits the needs of the organisation. To complete a project successfully everyone in the project team needs to be actively involved in the Risk Management and Good Governance aspects of a project. The length of the list of the forty four processes presented above isn't intended to imply that the majority of time spent on a project is spent updating risk registers, filling in time sheets and so on. To be clear, the "Task Management" aspects of project will take up the majority of team member's time. The above list is intended to illustrate the team member's responsibilities in risk management and governance in addition to the completion of tasks. By accepting they exist to improve the success of the project will help ensure the completion of the project within scope, schedule and budget.

References

I'm on a project... what now? (Part 2)

Sun, 05 Apr 2009 00:00:00 GMT

Part 2 : Tasks Management; Who does What to What Level, by When?

In the previous post I listed 27 activities other than "Task Management" or getting the work done. It's a long list, but the length of the list shouldn't be confused with the time needed to be dedicated to them. To be clear, completing tasks will take up 90% of a team member's time. Tasks are the majority of work on a project. Completing tasks is essential to completing projects.

Luckily all Task Management can be broken down into a simple formula: "Who does what to what level and by when". The "who" must be specific. It's not enough to have a task to be done by "Resource 1" or "Team Member". Tasks also require a scheduled completion date. This "when" is important so that the person(s) doing the task know when it is needed to be completed for the success of the project. The "does what" and "what level" must be defined not only so that the correct product is created, but also that the solution is not over engineered and time and money wasted on unnecessary "Gold Plating" of the product.

Who...

Clarity on who is doing a task is important. Each task needs to be assigned to an individual person. This can become complicated when multiple subcontractors are involved, but individual assignment needs to be done for two reasons. Firstly people need to know what work they are expected to do now and in the future. People can't be expected to manage their workloads without this. Secondly individuals vary widely in their abilities and if the estimates are based on another individual's ability then the schedule is wrong and deadlines improbable. For example; some computer programmers are up to 20 times [2] more effective than others. This variance of abilities differs between industries, but will always exist. Due to this variance in abilities and the simple fact that people need to know what is expected of them, clarity on which individual person is doing what task is important.

.does What to What Level...

The output of a task or the "does what" and "to what level" defines the deliverable for a task. It's important that the output is created, and it is equally important that the deliverable is reported once completed. Unfortunately for the team member, the best person to initially report on the completion and the quality of a deliverable is the team member(s) undertaking the task. The level of reporting differs between projects, but regardless of the industry or methodology; tasks are not completed until the output is measured and reported.

The reporting of a task complete is important for monitoring of the project and the effect the completion will have on dependent tasks and the rest of the project. No project tasks are as simple as flicking a switch "on" or "off", so the measuring of the task output is important to ensure that the task really was complete. This may be as easy as "1024 rows uploaded to the database" or the original level of quality may specified "30m³ concrete tested and approved by on-site inspector". The quality of the output needs to be specified and then managed by the team member.

In addition to the completion reporting, team members will often have to report progress on tasks as they are undertaken. This differs widely with PMs and the type of project. Progress indicators all have their problems, however they are just indicators to gauge the likely hood of completion and judge impact of the task on the rest of the project.

Project team members are on the project to create deliverables. It's also their responsibility to make sure the deliverables are at the required quality level and that the deliverable and quality is reported once complete. The team member responsibility for ".does what to what level." is just shorthand for "a task is only complete when it's completed to the correct quality, measured and reported."

.by When.

Scheduling has turned into a profession. There are certified estimators, and on large projects there are people whose sole task is to maintain schedules. Over the last two decades, some of the grunt work has disappeared with software like Primavera and MS Project. Even though the planning work has reduced, the "by when" of the task management formula is still just as important for individual team members.

The deliverables of a project are typically broken down into work packages and tasks. The tasks typically should be 4 hours to 5 days long. Any shorter and they generally should be grouped into another task, any longer and they pose a risk to the project. "Calling a courier" isn't a good task, but "verify and deliver contracts to vendor" is. "Create new maintenance planning system" isn't a good task, however "investigate requirements for equipment register component of maintenance planning system" is. Task that are too short introduce too much overhead, and frankly team members are involved for their expertise and should not need to report every switch pulled. Equally, it becomes difficult to judge the "doneness" of long tasks. Long tasks often remain at "90% complete" for 90% of the time and as such they pose a threat to their overall project. As a project team member, expect to be working to a list of tasks that have due dates 4 hours to 5 days from their start dates.

In addition to each project being devolved into many tasks, each task often interrelate; if task B depends on task A, then the delivery date of task A will certainly effect task B, and probably C, D, E and F. If Task A is late, then it is likely that Task F will be late and the project as whole late. To be more specific, the "by when" of all project tasks are important. In fact the due dates of early tasks are often more important as they indicate how well the rest of the project will perform and whether the project receives continued funding. Knowing when a task is due and delivering on time is a critical responsibility of a team member.

Task Management

Managing projects by "who does what at what level and by when" is a little surprising to some. Devolving your work life to Resources, Tasks, Due Dates and Results can appear a little cold. However it does simplify things, instead of spending hours in meetings "discussing issues" you'll be walking away early with an action list with just 4 columns; Who, What, What Level, By When.

Completing tasks is essential to completing projects. However making sure the tasks are the right tasks, and are completed correctly is why Risk Management and Good Governance are so essential on projects. I'll cover this in the coming third part of this series.

References
[2] Peopleware 3rd Ed, Page ?,Tom DeMarco

I'm on a project... what now?

Sun, 29 Mar 2009 00:00:00 GMT

Part 1 : What is a "project" and what do I do on one?

For the last few years you've been working at your company on day to day operations and improving things where you can along the way. Now you've just been told that you'll be starting working on the super important "Project XYZ" on Monday. There is a Project Manager, a Project WBS, a schedule, budgets, registers etc. You start to wonder how is this "Project" different from your normal day to day getting things done?

On a project you can expect to be responsible for;

Time Task Estimation. Identifying holidays and other non work times.	Scope Requirements investigation. Scope Verification.
Quality Checking received goods. Measuring the grade of the product or services produced. Reporting on completeness of your own tasks. Assessing the completeness of others tasks.	Cost Filling out timesheets. Creating requisitions. Approving requisitions.
Communications Input to or creation of regular communiqu�s for stakeholders. Consistent communications with stakeholders.	People Working ethically with other team members. 360 degree reviews of team members (including the PM)
Procurement Materials identification. Creating of requisitions. Vendor assessments. Evaluating quotes. Checking received goods against purchase orders.	Risk Initial risk identification. Creation of specific risks mitigation. Continuous risk assessment and analysis. Implementation of risk mitigation.
Integration Task management. Issue identification. Involvement in status meetings. Participate in Post Implementation Review (PIR)
Typical expectations of project team members in addition to task management.

If "Task Management" is about getting your project tasks done, what are all these other activities and why are they there? Why are projects different from your typical day to day operations?

In a lot of ways projects aren't that different at all. At the end of the day, a project is a still about undertaking work for the benefit of your organisation. However due to the unique nature of projects, more effort is required to ensure that the project is successful and is beneficial enough to justify the work. The difference in needs between successful projects and repetitive operational work are significant enough to require a slightly different mindset and often a different methodology.

The accepted definition of a project is "... a temporary endeavour to create a unique product, service or result." [1] Projects are different to operational work in that they have a limited time frame. Projects have a start and finish date. Projects are also different in that they create a unique item or service for the organisation. Building a new gold mine is a project, mining the ore isn't. Creating a new piece of software to monitor expensive tyres for 200 tonne vehicles is a project, regularly checking the conditions and updating the warranty details isn't.

At the very core, projects are about completing tasks to create something unique within a certain time frame. If projects are just about completing tasks, why the emphasis that projects are different? Two reasons; Risk Management and Good Governance. Not only must the project be completed by a certain time frame, it should be completed within the approved budget. The project should create something new for your organisation, but it should be something worthwhile. Also the "something new" your project creates should be the product requested when the money and man hours were approved, and should work as well as needed. Costs, scope, quality and risk management are all a part of Risk and Governance, and generally the PM will employ a framework or methodology to address these issues.

Projects can be broken down into two main areas: Risk Management and Governance, and Task Management.

The majority of project team member's time will be spent doing tasks. The majority of the PM's time will be spent managing risk and ensuring good governance. PMs who ignore the details of the tasks do so at their peril as do team members who ignore the risk and governance aspects of the project. In short, the concrete tasks as well as the risk and good governance components are equally important to everyone and the success of the project.

In practise there are "Just Do It" teams who just focus on tasks, there are also Project Managers who solely focus on the Risk and Governance side and never walk the floor or site. These types of projects are less likely to finish and if they do finish there will be a lot of unanswerable questions at the end such as; "how much did it cost?", "is it what we wanted?", "is it really finished?" In successful project teams everyone contributes to managing tasks, risk management and good governance.

Project Managers and their sponsors are responsible for the correct governance of a project; however estimates and risk registers will never be accurate if they are created by a PM who is locked away in an office somewhere away from the team. Good governance and risk management relies on the project team's active input at the start and through out the project. Conversely, completing tasks will take up of the project team's time. The team are the experts who'll undertake the various work packages and report on the quality once completed. The PM's role here is to communicate change that may have occurred elsewhere in the project to ensure the correct tasks are being undertaken. Also the PM monitors the team's performance and funds burnt to ensure there will be enough time and money left to finish the project.

Successful project teams need to be actively involved in the individual tasks as well as the overall risk management and good governance of the project.

Next i'll add some more detail on Task Management and Risk and Governance.

References
[1] PMBOK Guide 3rd Ed, Page 5, PMI

Ellipse Connector demonstration

Sun, 15 Feb 2009 00:00:00 GMT

Here is a Camtasia demo on a consistent look and feel solution for Mincom Ellipse Connectors that i put together last year for a client. The demo should good you a good idea of what the some of my previous suggestions could look like to a user.

Mincom Ellipse Connector Listing

I have been asked what sort of Connectors are contained in the above example. I'm not sure about posting and supporting the .XLA itself here but below is a list of a typical set of connectors for operations.

Finance

905 Journal Verify, Upload and upload multiple Journals. Use the 905 scripts to upload single journals, plus verify the contents of a journal. These verify tests include checking Mandatory fields for Work Orders and making sure the Work Order cost center matches the account used. This is extremely handy for large uploads.
905 Exchange Rate Download.
904 Transaction Modify Upload. This is useful for bulk changes to transactions. Such as Project or Work Order number.
950 Account Relationship Upload. Create and modify MSO950 relationships. Very useful especially if you manage your Balance Sheet and Op Statements by Relationships.
971 Budget Upload. Create and Modify budgets (automatically rounds to 0 d.p as well)
660 Bulk Project Upload and Close. Create, Modify and Close a list of Projects with the same template.

Maintenance

620 Bulk Work Order Upload, Print and Close. Create, Modify, Print and Close a lot of work orders in one go with the same template.

Stores

140 Requisition Upload. Create issue reqs. (easily modifyable to handle preqs if required)
220 Purchase Order Download, Upload and Cancel / Complete. Create, Retrieve, and cancel and complete POs in bulk. Very handy for PO clean ups to remove inappropriate liabilities in Invoice Pending etc.

HR

76T Exit Upload (ie: Terminations). Bulk Employee Terminations.
810 Employee Download and Upload. Create, modify and retrieve employees
832 Payroll Transaction Upload. Create payroll transactions. Extreemly handy for mass maintenance such as bonus payments.
830 Salary Increase Download and Upload. Retrieve the most recent salary rates, and upload new ones.
870 Position Upload. Modify positions.
891 Timesheet Upload. Create employee timesheet transactions.

System

020 Profile Upload and Delete. MSO020 security profile create, modify and delete. Can insert whole profile strings (250 characters) or easily modify one security position value across multiple profiles (global, program or signon)
020 Class Upload and Delete. Manage Class Method and Attribute settings across multiple profiles. This is very useful for say removing Employee.HomePhone, HomeAddress and Birthday access for all but HR profiles. Or specifying Requisition.Fetch to be "Own Reqs" for all profiles bar Supply.

If this is relevant to your workplace, feel free to contact me.

Six ways of improving Ellipse Connectors

Sun, 08 Feb 2009 00:00:00 GMT

Mincom's Ellipse Connectors are a great way to connect to and update Ellipse from applications like Excel. The most common way of doing this is creating a set of separate XLS files with some code in them files and putting them in a central location. Most often this slowly creates a mess of unmanaged and undocumented applications, of which we don't know who is using what and what works and what doesn't.

To address these problem takes some discipline, but it takes more of a change of mind set. The Ellipse connectors that your company uses are not just sets of spreadsheets, they are major Ellipse user interface for many users. They should be secure, logged and managed as such.

I have seen several reoccurring problems across a lot of Ellipse implementations. Luckily they all have some very simple solutions.

Problem: Unsecured Code.
Since code stored in XLS is modifiable if you can modify the file itself, why not store all code in a an Add In? This is very simple with Excel; you create an Add-In (a .XLA), or you can create a Dynamic Library ( a .DLL file) for the rest of the Office products. That file can be protected against your users writing to it.

Problem: Distribution.
This is often solved by putting multiple .XLS on the network (or Citrix). However a single .XLA is a lot easier to distribute whether you have fat clients installed on local machines or not.

Problem: Bugs.
Well i can't solve all of your bugs with a single tip, but by creating a standard library of code for the often repeated functions (eg: formatting sheets, logging, even TableFile interactions) you will save a lot of time initially coding, and save a lot more time maintaining your code. Imagine using a single one line function call to Create010TableFile()? This frees up a lot of time from mundane Copy & Paste coding.

Problem: Lack of a consistent look and feel.
This can be a simple as every Connector using different colours and layout, or can be more insidious of each connector behaving differently. Often i've seen users having to remember that this Connector must have dates like 20090129 and that Connector accepts 29/01/09, some scripts treat a blank as "do nothing" while other treat a blank as "delete the data in the field". This problem can be fixed by code reuse and libraries (see last point) and a few standards. By implementing code libraries you'll solve most of these problems straight away and make your users lives a lot easier.

Problem: Lack of usage statistics
How can you manage a system without knowing who uses what and how often? Do you just listen for the most vocal group in your enterprise? Hopefully not. By using reusable libraries (ie: a .XLA or .DLL) it's very simple to put in a usage logger with details of the time, user and which Connector application they are running. In the past i have done this to a centralised web server (if you have multiple form servers or fat clients) or a simple .CSV file if you have a single Citrix implementation. Very easy to set up and you'll know what and who you need to concentrate your development effort on in the future

Problem: Lack of version control
This can be a tricky problem to solve. How do you make sure that hundred or thousands of users are using the most up to date version of your code? The solution is often very tied to your client implementation. However no matter what distribution and client method you are using, it's very easy to implement a central register that gets called each time a user runs the connector which checks the name and version number and then either allows, denies or warns the user appropriately. Sounds complicated? This can be implemented in under 20 lines of code with most web servers.

The purpose of addressing these problems is making your users lives easier, and freeing up your developers time from dull copy and paste scripting so they can focus on making something awesome.