Work smart, not hard - An approach to time-sensitive project management

-A A +A
People who work “hard,” put in extra hours, check their email on nights and weekends, and maintain a rapid pace, even when they’re tired, are admirable; They are motivated, well-intentioned people who want to do a good job. BUT people who work “smart” understand the power of pausing and creating the freedom to think, plan and develop their business

By PMI (Project Management Institute)

Abstract: “Work smart, not hard!” – An Approach to Time-Sensitive Project Management

Limited budgets and resources and outside competitive pressure have increasingly strained the time-line of IT projects and software development efforts. The scope of IT projects has not necessarily changed though. Project teams often have to deliver the same scope with less resources and lower budgets. As a consequence, the effort project teams have to invest increases. Even more seriously, the quality of the delivered solution may suffer.

This need not be the case. The presentation shows that time-sensitive projects do not automatically need to lead to longer working hours and lower quality. Instead of working harder, the presentation encourages to work “smarter” with the given resources. A “smarter” working style implies an efficient and results-oriented and thus effective working style. The paper describes four characteristics and critical success factors of a smarter working style. It discusses both static factors that stay constant across projects as well as dynamic, project-specific factors that deserve special attention.

All findings are illustrated by real-life examples from a CRM project in which a fully functioning call centre solution was implemented in the record time of 15 ½ weeks. The motto “work smart, not hard!” was one of the principles that guided the team's working style. It contributed to the on time and on budget delivery of the project.

Anticipated Outcome

The presentation will show the following

  • Time-sensitive projects need not imply poor quality results and burnt-out, demoralised individuals.
  • A smart, i.e., efficient and results-oriented, working style helps manage time-sensitive projects successfully.
  • There are four main characteristics and critical success factors for smart work to prosper:
    1. 1    The project has a clear and mutually agreed and understood project and business objective and project deliverable.
    2. 2    Principles of balanced planning and time management rules are applied.
    3. 3    The application of appropriate standards and templates and the existence of a supportive infrastructure.
    4. 4    Team building measures ensure synergy effects from teamwork.
  • A smart working project manager is great. A smart working team is better.

Introduction: The Need for Time-Sensitive Project Management

Limited department budgets and resources and outside competitive pressure have increasingly strained the timeline and budgets of IT projects and software development efforts. The scope of IT projects has not necessarily changed though. Project teams often have to deliver the same scope with less resources and lower budgets. As a consequence, the effort project teams have to invest increases. Even more seriously, the quality of the delivered solution may suffer.

This need not be the case. This paper will show that time-sensitive projects do not automatically need to lead to longer working hours and lower quality. Instead of working harder, the author encourages to work “smarter”. A “smarter” working style implies an efficient and results-oriented and thus effective working style.

The paper describes four characteristics and critical success factors for a smart working style to prosper. They are:

  1. 1    The project has a clear and mutually agreed and understood project and business objective and project deliverable.
  2. 2    Principles of balanced planning and time management rules are applied.
  3. 3    The application of appropriate standards and templates and the existence of a supportive infrastructure.
  4. 4    Team building measures ensure synergy effects from teamwork.

The paper does not claim these characteristics and critical success factors to be exclusive, i.e., the only factors for the success of time-sensitive project management. Far from it. Managing projects is a complex task. The aim of the paper is to outline one approach to time sensitive project management.

All findings are illustrated by real-life examples from a CRM project in which a fully functioning call centre solution was implemented in the record time of 15 ½ weeks. The motto “work smart, not hard!” was one of the principles that guided the team's working style. It contributed to the on time and on budget delivery of the project.

The following section describes the challenges and desired benefits as well as achievements of this CRM project in greater detail. Afterwards, the paper explains how the four mentioned characteristics and critical success factors of a “smart” working style account for a good start into a time-sensitive project. The third section of the paper describes necessary steps for the critical success factors to continue to be fulfilled once the project is on the way.

The “OptiFrend” Project

In 1999 a direct banking branch of one of the largest banks in Germany decided to replace its two “pencil and paper call centres” with a modern CRM call centre.

The provider of the selected software package recommended a minimum of 20 weeks for the integration, the bank faced a fixed live date only 15 weeks away. Other challenges the bank faced were data interfaces and data security, uncertain acceptance of end users, a new software release and project risks of on time and in budget delivery with the expected quality. The goal was to optimise the workflow, include reporting features, have high user acceptance and improve customer satisfaction.

The bank asked Cambridge to help integrate the technical solution of Clarify's (Amdocs) eFrontoffice Version 9 and the modules ClearCallCenter and ClearSupport built on SQL Server 7.0 (NT Service pack 6). The project itself was named “OptiFrend” which stood for the development of an “optimal front-end”.

The Cambridge team consisted of 8 full-time resources: 1 project manager, 1 technical team manager who also functioned as the data business administrator, 2 senior developers, 3 associate developers. The team was supported by part-time senior technical consultant (10%) and 1 engagement partner who was primarily responsible for client and contractual issues. The bank provided 1 full-time project manager, 3 part-time functional experts and 1 part-time technical resource. The head of the IT department sponsored the project.

Cambridge divided the project into five distinct phases. The first project phase (Scope) started in October 2000 for two weeks followed by 5 ½ weeks of specifying the design (Design phase) and a quick development (Development phase; December 2000 - January 2001) as well as testing and final rollout (Testing and Rollout phases). The live-date on February 1st, 2000 went without any complications. By early March 2000, a total of 82 call centre agents in two locations were supported by the new call centre solution.

As a result of the project, the bank achieved its business goals. It collected more customer data, which could also be used for reporting purposes. The call centre application became a solid foundation for an extended CRM strategy. Since the first phase of the project, the bank added numerous functionalities to the application. Most important, the application allowed the bank to provide helpdesk services and solutions to third parties and vendors. Customer satisfaction improved noticeably due to better customer service. For example, call centre agent could now view the complete contact history and any pending cases. Consequently, the call centre agents are always informed about previous calls of the customer and can focus on the solution of a new problem right from the start. In case of more complex questions, call centre agents have access to an internal knowledge database. Job satisfaction improved by being able to please customers. Cambridge, on the other side, was happy because it was able to deliver on time and in budget. It was one of the fastest Clarify implementations in Central Europe. The many collected lessons learned were valuable input to the company's Clarify competency centre.

Laying the Foundation for Smart Work Before the Start of a Project

Clear Scope and Expectations

A smart, results-oriented working style requires an understanding of the objective of the project. It is absolutely crucial to know the goal and targets of a project right from the start. Unless the project's goal is not predefined, it is highly recommended to organise a goal definition workshop at the very beginning of a project. In the case of the OptiFrend project the business objectives were already defined during the presales phase. The time frame of the project was set by a fixed live date. All four team members of the bank were trained in the new software and had a basic understanding of its functionality. Customisation of the application should be reduced to an absolute minimum. This would ensure that future updates could be realised with less design and development effort. In addition, the client understood that it would not be possible to have every possible call centre functionality implemented in the first release. Instead, the project team focused on designing and developing functionalities for those processes that generated the greatest business benefit (80:20 rule). Processes and functionalities with a lower priority were documented for considerations in later releases.

While it may sound trivial, the project objective and the deliverables have to be in writing. Project objectives, deliverables, time frames, risks and critical success factors have to be described explicitly and leave no room for second-guessing or interpretation. The wording should be easily understood by all involved parties, from the sponsor down to the associate developer and end user.

Project objective(s) should be described both from the business and the technical perspective. It is a mistake to believe that IT projects do not have to explicitly account for business factors. After all, most IT projects are realised for business departments. If in doubt, business objectives should drive IT projects, not the other way around.

Choosing and Applying Balanced Planning and Time Management Rules

A smart working style is reflected in the project planning process. The project manager needs to have a good understanding of all necessary design and development steps. A good project plan is based on realistic assumptions. For example, it is unrealistic to assume that every team member can be productive 100% of the time. In the OptiFrend project a working day was defined to have 6 instead of 8 hours. This left enough room for unexpected tasks and delays such as change requests or administrative duties. The average weekly working hours were seldom above 45 hours. Productivity and morale were high and burnouts could be prevented.

Additional estimation rules and principles that prove to work are the following:

  • Be explicit about the underlying assumptions of estimates and the project plan. Document all made assumptions and track any changes made if any. A project plan falls within its assumptions, so do the project deliverables and hence project success.
  • Include identified risks into estimates based on a defined procedure.
  • Gather independent estimates from several experts. At the OptiFrend Project a disproportionately high amount of time was spent conducting estimations. Involved persons were not only the PM, but also the technical team manager, another senior technical consultant and even the senior developers on the project. Having heard so many opinions it was possible to build a project plan that barely required rescheduling during the project.
  • Communicate estimates and the underlying assumptions to the project team and the customer clearly. Check for understanding. Especially the critical paths need to be crystal clear to each team member.
  • Planning sessions following the rule of thumb proved to be successful at the OptiFrend project:
    • Sessions took place mostly in the mornings except for Mondays. The afternoons were reserved for session preparation and consolidation.
    • No more than two sessions took place in the morning unless different people were involved. This helped avoid mental burnouts. Sessions started and ended on time. This was only possible with clear session objectives and agendas, which were communicated at least one day before.
    • It turned out that 1 session hour required 2 hours of preparation time and 2 hours after the session for rework and documentation.
  • At the OptiFrend project the development of the graphical user interface (GUI) of the application, GUI design and development accounted for 20% of the time, coding 40%, testing 20% and documentation another 20% of the time. These numbers were included in all development estimates.
  • Planning the training of the end-users can be estimated that 1 training day requires 15 days of preparation. It is wise to treat the preparation of the end user training as a separate mini-project, which increases the PM tasks by an additional 10 to 20%. Human resources have to be co-ordinated since some key players of the development project, such as the technical team members or client key users, also take part in the training project.

A smart planning style prioritises tasks and focuses on the most important ones. It takes enough time to plan for it; planning time is planned in right from the beginning. On the same token, planning should not be exaggerated. A smart planning style plans what is truly needed and cuts the rest.

Preparing Standards, Templates, and Infrastructure

Standards

Smart planning by itself is not sufficient for a smart working style to prosper. There has to be a set of standards and tools that build a methodological framework for the project team. As many methodologies exist, the project manager has to ensure that he/she uses the right amount of tools to manage the project and not the other way around, i.e., the tools dictating how a project is run. Time-sensitive projects do not yield the time to invent the wheel from scratch. Instead, it is recommended to use those tools that are available.

Naturally, it is assumed that the project manager has a good understanding of the company's methodology. He has to make sure that the whole project team has a solid grasp of the methodological tool kit. In addition, it is important that the client is open to the used methodologies. The client should understand the basics of the chosen approach and working style prior to the project start. Fortunately, this was the case in the OptiFrend project. The client was very receptive to new approaches, templates and working styles and embraced them. It made project life much easier for the whole team.

Templates

An important element of the chosen methodology is document templates. Preparing appropriate templates before the beginning of a project can turn out to become a significant time saver. Documentation is a very time-consuming process. Having set up the right templates is a simple, but very effective, time saver. It allows team members to focus on content rather than format. Consequently, templates should be shared with all team members and be easily accessible for everyone without having to search for them (“Find instead of search!”). This may, but need not, call for a common project server. As with any templates, they can be arranged during the project to meet specific needs.

In the OptiFrend project the following templates were prepared prior to project start:

  • minutes,
  • weekly status reports,
  • documents of the different project phases (e.g. Scope and Design documents),
  • project plans (scope, design, development, testing, rollout, training),
  • and a project folder structure for the team server and own computer.

It is frequent that documentation is neglected in time-sensitive projects. Given that documentation can be a significant project deliverable (such as after the Scope and Design phases), this neglect can be fatal. Documentation should be given a central role in any project.

Another helpful time saver can be to set up a sound folder structure for the team server and one's own computer. The project manager should explain the logic of the folder structure to the team members and make sure that the team uses it correctly. There is no best or worst folder structure as long as it works. There should be the right amount of folders and subfolders. Less can be more. A folder structure is dynamic. It will most likely have to be expanded during the life cycle of a project. If the project office does not recommend one, ask other project managers for their input. Experience pays off. Along with the folder structure define a rule for naming files before the first file is copied to a project folder. For example, in the OptiFrend project all minutes started with the date of the session (year/month/day) followed by the title of the session (e.g., “20001009 Process Analysis.doc”). This way minutes are always listed chronologically. It can help cutting down search time.

Infrastructure

Another important thing than should be ensured to be in place before the project start is the technical team infrastructure. This includes a printer, a project server including access rights for all authorised team members, all necessary software (e.g., MS Office, MS Project, PVCS issue tracker, SnagIt software for easier screen shots). It is advised that the team's computers have the same operating system. Furthermore, a hub, router, cables, and a sufficient number of telephones should be available at a project site on the first day of the project.

Often times, team and session rooms are rare and cannot be assigned permanently to a project team. The experience of the OptiFrend showed that it pays off to have a permanent project room where the team is working, one additional team room for internal meetings and later for end user testing, and one permanent session room. If the team has to change team rooms it often creates distress and distractions. The client should be made aware of the value of providing a supportive infrastructure. Eventually it benefits him, too, because it helps improve productivity of the project team.

Planning Team Building Measures Right From the Start

A project manager without a functioning team is not worth half of his value. It is the core responsibility to build and manage a well-functioning team. A team is not merely a gathering of specialists for a given time. Teamwork connotes work distribution and group dynamics. The art is to distribute work effectively and build a foundation for synergy to develop. Forming a team starts with finding the right team size. The author's experience shows that the optimal team size seldom exceeds the number of 9 to 10 resources. The OptiFrend project consisted of the following 8 full-time people:

  • 1 Project Manager (100%)
  • 1 Technical Team Leader and Database Administrator (100%)
  • 1 Senior Technical Consultant (20%)
  • 2 Senior Developers (100%)
  • 2 Associate Developers (100%)
  • 1 (experienced) Business Analyst (100%)

In addition to the core team, there was a Senior Technical Specialist (20%), an Engagement Partner (20%) who took care of client relationship on the management level, and an Account Manager (<5%) who was accountable for contractual issues of the project.

A good skill mix in a team is important. On the same token it is not always necessary to have only experts on the team as long as a mentorship program is in place for less-experienced team members. During the OptiFrend projects senior developers served as mentors to associate developers. This allowed an active learning environment to develop.

The team met the first time about one week before the project start for a team norming. The goal of the team norming was multifold.

  • Discussing the content and scope of the project on a high level. Background information about the client and the presales chronology was shared. The official objective and scope of the project were presented.
  • Explaining the various project roles, responsibilities, and expectations for the first project phase (scope). Rather than explaining the distribution of work on an individual one to one basis, the roles and distribution of work as well as their meaning were discussed with the whole team. Each role was explicitly described. This secured the buy-in from the respective person. In addition, it ensured that everyone on the team knew what the other team members would be primarily working on. The goal was to achieve a balanced workload and an effective and efficient distribution of work.
  • Discussing and defining ground rules. Ground rules covered topics such as working styles (“work smart, not hard”; rules for documentation; use of available methodology, etc.) internal and external communication principles and escalation channels, core working hours, and social team events.
    • During the OptiFrend project the team agreed on the following round rules:
      • Communication
      • Open communication
      • Constructive feedback only
      • Regular (if necessary daily) reminders of communication channels
    • Respect
      • Treating each other with respect.
      • Listening to everybody
      • No group pressure, team-setting norms not taking into account individual interests (e.g. long working hours, etc.)
      • Recognize and value everyone
    • Fun
      • Plan and organise regular team events
    • Attitude
      • Open to reuse/use provided methodology
      • Full dedication of each member
      • Stick to own responsibilities
      • Everybody takes initiative
    • Clint integration
      • The whole team is responsible for creating a pleasant work atmosphere with the client.
      • Introduce the whole team to the immediate work environment (clients working on the same floor or same room.)
      • Organise joint team events with the client early (before and during the project)
  • Providing logistical information such as project site, accommodation, and travel policy.

The team norming guaranteed a clear understanding of everyone's role and expectations right from the start. As such it is the key to building a foundation for developing a functioning team and team synergy. The team norming was prepared by the project manager, technical team leader and engagement partner. It was facilitated by a third person and lasted about 4 hours. All results of the team norming were documented in a protocol.

Working the Dynamics

The previous section explained what can be done before the start of the project to ensure that a smart working style becomes feasible. The same four mentioned characteristics and critical success factors apply during the course of a project. This is the topic of the following section.

Effective Scope Management

Effective scope management should be carried by the whole project team and involved parties. The project manager ensures the understanding of the agreed scope. This is especially important at the beginning of a project, but it does not stop there. Even for projects with a crystal clear objective and scope description, chances that the client or the project team requests a change to a functionality, approach, deliverable, or timeline are great. The art is to keep control of the scope nevertheless. The prerequisites for an effective scope management (having a clear business objective, definition of the scope and deliverables) have been explained in the previous section. It doesn't stop there. The client and the project team have to be continuously reminded of the objective and agreed scope. Technical decisions about an architecture or a certain functionality, for example, have to be in sync with the agreed business objectives and scope. This is achieved by generating a list of factors that are used to prioritise functionalities, technical and business decisions. The list by itself should be limited to 3 to 5 aspects in order to prevent endless discussions. Whenever there is a change request it has to be evaluated based on the predefined criteria. Only if it fulfils all or most criteria should it be further assessed. To a third uninvolved party this mechanism may appear to be overly restrictive and inflexible. It is not. Any significant change request will pass the first check. If someone considers the necessary paperwork too much of an effort, the change request is likely not significant either.

The assessment considers the impact of the change request on the cost, timeline, and other functionalities. Needless to say, every change request has to be thoroughly documented for later reference. The ideal scenario is that there is no need for change requests as all desired functionalities and features had been considered early on. Chances for this scenario are increased by proper documentation of all sessions and decisions. No doubt, this is the most efficient way. A more realistic scenario though is that change requests will be submitted during the lifetime of a project. The question is how effective and efficient they will be handled. It pays off to take the necessary time to plan, document and agree on a change request process early on and then have the necessary discipline to follow it. In addition, people should be reminded again and again of the objective(s) and scope. The project and business objectives should be paramount in all-important documentation, including technical documents. Constant reminders of the objectives are certainly cheaper and greater time savers than time consuming and costly change requests. Last, but not least, an effective scope management is lived by the whole team, not just the project manager. The project manager is accountable for a successful scope management; but it is the responsibility of every team member. This is yet another reason for setting up a solid scope management and explaining the reasons and process behind it to everyone involved.

Time Management on a Macro and Micro Level

It is the responsibility of the project manager that proper time management rules are in place. This is widely accepted fact. On the other side, the best time management rule is worthless if it is not followed by the whole team. Similar to the scope management, time management is highly dynamic. It needs to be adjusted to meet the changing daily requirements in a project. Submitted change requests serve as examples. Other examples are circumstances such as sickness or late deliverables. The project manager cannot plan every task of his team members to the last detail. However, he can control the results. An efficient mean to do so is to conduct regular sync meetings with the team. These sync meetings have the goal to give every team member an update on the progress of individual tasks. During the OptiFrend project sync meetings were conducted daily for the first two project phases (scope and design) and twice a week during the development phase. Prior to the sync meeting, individuals wrote down their task updates on sticky notes. They were collected and then briefly presented. In addition to task updates the following topics were discussed:

  • Technical or functional issues (individual problems, potential change requests)
  • Observations about the client
  • Team issues (likes or dislikes)
  • Methodological tips and tricks and lessons learned

Similar to the task updates every input to the other topics was written on a sticky note by each team member (one input on one sticky note) and collected. In order to limit the duration of the sync meetings, status and issues were only presented; there was no discussion or solution suggested unless it was team related. The focus was clearly on sharing information thus ensuring that everyone was on the same page. Open issues and action items were documented similar to minutes and were left hanging on flip charts every team member could see. Every issue or action item was assigned to somebody responsible for solving and the results were tracked. In addition to the daily sync meetings there was a weekly wrap-up meeting. This meeting also functioned as a preparation of the weekly status report for the client. Conducting daily sync meetings helped knowledge and information sharing to become a daily routine.

The OptiFrend project also showed that it best to conduct sync meeting no later than 5 PM. This left enough room for people to work on open issues or action items the same day. It also prevented group pressure to build up to staying late and working long hours. What counted were results. It was up to the individual to finish his or her task by a reasonable hour or work late. As a result, productivity was high throughout the day.

Another helpful feature of the sync meetings was that everyone was encouraged to share one's experiences with suggested time management rules, methodologies and other lessons learned. This way the sync meetings became not only a forum for information, but also knowledge sharing. It helped build a dynamic learning environment and facilitated time management on both the macro and micro level. As individuals became more aware of time saving measures, they shared their experiences with and helped each other work smarter.

The sync meetings and the resulting dynamic learning environment turned out to be a very effective way to help everyone work smarter. It did pay off to have at least 30 minutes planned in for structured sync sessions. It is recommended to have one facilitator who need not always be the project manager. Furthermore, results should be documented. This applies especially for open issues and action items that need to be tracked.

Use of Standards and Templates

Experience shows that documentation is often one of the things neglected in time-sensitive projects. In the beginning of the project it is often procrastinated till the end of a project phase. Not surprisingly, the resulting documentation may lack the necessary depth and quality. Given that the time pressure is usually the greatest towards the end of a project phase, it is even more important to ensure ongoing documentation.

One of the basic elements of documentation is accurate and thorough session minutes. During the OptiFrend project team members were asked to write the minutes in a format so that the content of the minutes can easily be copied to the final scope or design document. Minutes had to be written according to the “MECE” principle: They had to be Mutually understood, contain only Exclusive information, they had to be Comprehensive and Exhaustive. The MECE principle helped avoid misunderstandings; potential room for interpretation was eliminated. In addition, the MECE principle made it easier for a third person to learn about the results of a session. The template was structured in a way that made it easier to follow up on identified action items or open issues.

While it took longer to write the minutes in a MECE style, the time saving effects with regards to later documentation were significant. The minute taker prepared the minutes immediately after a session, usually in the same session room. This way he was not distracted when returning to the team room.

Due to the importance of documentation, it is recommended to assign a documentation manager for the various project phases. He or she checks that documentation is ongoing, thorough and accurate and in accordance with the templates and quality guidelines. The documentation manager need not be the project manager. To the contrary, it is advised to assign this responsibility to someone who is more involved in the content of a project, such as a developer, as it was done in the OptiFrend project.

Team Dynamics

A team norming is one of, if not the most, important measure to build a successful team. Still, it cannot always prevent conflicts from arising. Every team has to pass through a forming, storming, and norming phase in order to get to a performing stage. A team norming improves the chances that the team arrives at the performing stage earlier. Besides an explicit description of the roles the team has to be made aware of the fact that most likely there will be a storming phase. Once a team realises it is in a storming phase, the whole team should revisit the minutes of the initial team norming. Misunderstanding have to be solved, expectation clarified, and role descriptions as well as ground rules have to be adjusted. In the case of the OptiFrend project, the team experienced a storming phase after about 5 weeks into the project. Once the team became aware of it, it met to revisit the results of the team norming and make necessary modifications. As a consequence, the responsibilities and expectations became clearer. The team started to perform and synergy effects became apparent.

Synergy effects from teamwork can be the greatest time saver of all. Hence, the project manager should spend sufficient time to initiate good team dynamics and plan in team building events. It is one of the best time investments and a prime example of smart work. It is true that a smart working project manager is great. A smart working team is better. It understands and lives the principles of smart work and allows synergies to result. As a consequence, it becomes easier to manage time-sensitive projects.

Summary

Time-sensitive projects need not imply poor quality results and burnt-out, demoralised individuals. This paper showed that a smart, i.e., efficient and results-oriented, working style helps manage time-sensitive projects successfully. It described the four main characteristics and critical success factors for a smart working style to prosper:

  1. 1    The project has a clear and mutually agreed and understood project and business objective and project deliverable.
  2. 2    Principles of balanced planning and time management rules are applied.
  3. 3    The application of appropriate standards and templates and the existence of a supportive infrastructure.
  4. 4    Team building measures ensure synergy effects from teamwork.

The paper does not claim these factors to be exclusive. However, they are central for a smart working style to prosper. The project manager can lay the foundation for a performing team and high quality results if it fulfils all four factors. Preparation time prior to a project is minimal compared to the potential time saving effects. In the case of the OptiFrend project total preparation time was about 2 days and 1 team day for the team norming and infrastructure set-up. While the software vendor recommended 22 weeks to complete the project, the new call centre solution went live after only 15 ½ weeks. This was a net time saving of 6 team weeks! The motto “work smart, not hard!” was one of the principles that guided the team's working style. It contributed to the on time and on budget delivery of the project.

As simple as the slogan “Work smart, not hard” may sound, it contains valuable principles and guidelines for successful time-sensitive project management.

References

DeMarco, T. & Lister, T. (1999). Page: 11

Peopleware: Productive Projects and Teams (2nd edition). New York: Dorset House Publishing.

Standish Group International, Inc. (1999) Chaos Report

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

PMI Congress Europe 2003

CONFERENCE PAPER Information Technology 25 May 2003
Juli, Thomas

Juli, T. (2003). Work smart, not hard!: an approach to time-sensitive project management. Paper presented at PMI® Global Congress 2003—EMEA, The Hague, South Holland, The Netherlands. Newtown Square, PA: Project Management Institute.

May 22 – 26, 2003
The Hague, the Netherlands
Submitted on April 28, 2003

Thomas Juli, Ph.D.
c/o Cambridge Technology Partners (Deutschland) GmbH

Zeil 79, 60313 Frankfurt am Main
Tel.:     +49 (0)172-655 3855
Fax:     +49 (0)69-2174 1740

Category
PMP - Project Management Best Practices

Tags

Nguồn
PMI