A Stage Gate Is Not a Date: Why Design Readiness Needs Evidence

Projects need dates.

Concept Design needs an end date. Schematic Design needs a milestone. Developed Design needs a point at which cost planning, approvals, tender preparation or procurement can move forward. Consultant programmes cannot operate without these boundaries.

But a date is not the same thing as readiness.

A project can arrive at the end of a design stage with drawings issued, presentations approved and consultant deliverables uploaded, while still carrying unresolved decisions that the next stage is about to inherit.

That is the difference between programme completion and design maturity.

A stage gate should test the second.

Why stage dates become dangerous

The programme itself is not the problem. The problem begins when the project starts using the date as evidence that the design is ready.

A concept package may look coherent while the services zones have not been protected. A room or tenancy module may be approved while structure and MEP implications remain untested. A fire strategy may exist but may not yet be reflected consistently across disciplines. An authority pathway may be assumed rather than confirmed. An operator comment may have been acknowledged but not incorporated. A cost plan may be based on information that is still moving.

None of these conditions automatically means the project should stop.

They do mean the project should know what it is carrying forward.

The project has moved. The risk has moved with it.

What an evidence-based stage gate is actually testing

A useful stage gate is not a ceremonial approval meeting. Nor is it an attempt to freeze every detail too early.

It is a decision about whether the information produced at one stage is sufficiently mature for the next stage to rely upon it.

That requires a different set of questions from "Have the drawings been issued?" or "Has the client signed off the presentation?"

Has the purpose of the stage actually been achieved?

Are the major decisions visible?

Have the critical multidisciplinary interfaces been tested to the level required at this point?

Are approval assumptions clear?

Has cost advice been based on information that genuinely represents the current design?

Are unresolved matters classified and owned?

Can the next team understand what it may rely upon and what remains conditional?

These questions do not demand perfection. They demand honesty about maturity.

Different stages need different evidence

The evidence required at Concept Design is not the same as the evidence required before tender or construction.

At concept stage, the project may need confidence that the basic asset logic works: access, massing, room or tenancy modules, vertical circulation, broad structural logic, service zones, fire principles, operator or client requirements and likely approval constraints.

At schematic design, the technical systems should be becoming credible. Plant space, major risers, MEP zones, structural interfaces, room data, BIM deliverables, cost assumptions and approval risks should be visible at an appropriate level.

At developed design, the project should be testing whether the consultants, authority requirements, operator/client decisions and cost decisions are genuinely coordinated.

Before tender or construction, the threshold becomes much higher. Drawings, specifications, schedules, room data, long-lead decisions, authority conditions, value-engineering changes and procurement assumptions need to tell a consistent story.

The gate therefore changes with the stage.

The principle remains the same: what is the next stage entitled to rely upon?

Not every uncertainty has to disappear

No complex project reaches a stage gate with every future question answered.

Some information is intentionally developed later. Some specialist design cannot be completed before procurement. Some authority matters remain subject to review. Some client decisions may be carried for a limited period because other work can proceed safely around them.

The problem is not residual uncertainty.

The problem is invisible residual uncertainty.

A mature project should be able to distinguish between three conditions.

First, matters that must be resolved before progression because the next stage cannot safely work around them.

Second, matters that may proceed conditionally because the residual risk is understood, an owner is identified and the consequence is acceptable.

Third, matters that are legitimately not yet active but must be picked up at a defined future point.

That distinction allows a project to move without pretending that every issue is closed.

Proceed, proceed with accepted risk, or do not proceed

This suggests a practical way of thinking about stage-gate outcomes.

A project can PROCEED when the stage purpose has been achieved and the remaining open matters do not undermine the reliability of the next stage.

It can PROCEED WITH ACCEPTED RISK when specific unresolved matters are visible, owned and judged acceptable for a defined period.

Or it can DO NOT PROCEED when the design is being asked to move forward while carrying issues that make the next stage unreliable.

The middle category matters.

Projects often need to progress before every uncertainty has disappeared. Governance should not become a reason to stop intelligent progress. But conditional progression should be explicit.

"We know this is unresolved, we know what it affects, we know who owns it, and we know when it must be closed" is very different from "we will sort that out later."

Risk acceptance is also a design decision

Sometimes a project knowingly proceeds with an unresolved matter. That can be entirely reasonable.

The question is whether somebody with the appropriate authority has understood what is being accepted.

What is the unresolved condition?

What are the plausible consequences?

What future work depends on it?

What would trigger escalation?

When does the risk become unacceptable if it remains unresolved?

Who has authority to accept it?

If those questions are not visible, the project is not really accepting risk. It is simply allowing uncertainty to travel.

What proves readiness?

Readiness should leave evidence.

The form of the evidence varies with the project and stage. It may include coordinated drawings, a model review, a signed-off decision, an updated cost plan, an authority response, a completed design-risk review, an operator comment closure record, a room-data milestone, an agreed procurement strategy or a documented residual-risk register.

The point is not to create a thick stage-gate report for every project.

The point is that the decision to progress should be based on more than a date and a feeling.

The evidence should answer the questions the next stage will depend upon.

The missing link: downstream dependency

One of the strongest ways to test readiness is to look forward.

What does each unresolved issue block next?

If a plant-room decision remains open, can the structure progress? Can the services routes be fixed? Can acoustic treatment be designed? Can procurement move?

If an operator decision is outstanding, does it block room data, MEP, FF&E, mock-ups or cost planning?

If an authority matter is unresolved, does it threaten consent, building form, access, fire strategy or staging?

If a value-engineering decision is not incorporated, can the tender package be relied upon?

This downstream view changes the stage-gate conversation.

Instead of asking only whether the current team has finished its deliverables, the project asks whether the next team has trustworthy inputs.

Closure must also be real

Another common stage-gate weakness is the use of status labels without evidence.

An issue may be marked closed because it was discussed, because a consultant responded, or because the client acknowledged the recommendation.

But if the issue affects design information, the project should be able to show where the consequence has actually been resolved.

A revised drawing. An updated model. An amended specification. A recorded approval. A cost-plan adjustment. A procurement confirmation. A certificate.

Closure evidence is important because stage gates are transfer points. The next stage should not have to rediscover supposedly closed issues.

Who should participate in a stage gate?

A stage gate should not become the design manager's private judgement. The value comes from assembling the perspectives that the next stage will depend upon. Depending on the project, that may include the client, architect, engineering leads, project manager, cost consultant, BIM or information lead, operator, contractor adviser and relevant statutory specialists.

The group does not need to review every drawing. It needs to test the small number of conditions that define readiness at that point. The cost consultant may confirm whether the current information supports the cost plan. The approval lead may identify conditions that still affect design. The BIM lead may confirm whether the model exchanges are aligned enough for the intended use. The operator may identify unresolved standards that would otherwise become late changes.

This multidisciplinary view is important because design maturity is rarely owned by one discipline. A package can be complete within architecture while still being immature as a project input.

What should a stage-gate record contain?

The record can be concise. It should show the gate decision, the evidence reviewed, any mandatory closures, any residual risks being carried forward, the owner of each carried item, the downstream dependency and the date or trigger by which the matter must be resolved.

That record becomes part of project memory. When a question reappears later, the team can see whether the risk was unknown, accidentally missed, or consciously accepted. That distinction matters commercially and professionally.

Stage gates are not bureaucracy

The phrase "stage gate" can sound corporate. Used badly, it can become bureaucracy: another meeting, another checklist, another approval box.

That is not the objective.

Good governance reduces confusion. It should concentrate attention on the few things that matter most at the transition point.

A useful gate makes open risk visible, clarifies responsibility, records what is being accepted and protects the next stage from unreliable information.

It should make projects faster by reducing avoidable rework, not slower by adding ceremonial process.

Stage gates improve learning as well as control

There is another benefit. When the same stage-gate questions are used across several projects, patterns become visible. A developer may discover that authority assumptions are repeatedly being carried too late. A design practice may see that plant and riser space is routinely under-tested at concept stage. A contractor may find that specification alignment is a recurring tender problem.

Those patterns can improve future briefs, consultant scopes, fee allowances and project programmes. The gate is therefore not only a control point for the current project. It can become a learning mechanism for the organisation.

The senior question

At every stage transition, one question deserves to be asked plainly:

Can the next stage safely rely on what we are handing over?

If the answer is yes, proceed.

If the answer is yes with conditions, record the conditions and the risk owner.

If the answer is no, a programme date should not be allowed to disguise the problem.

A stage gate is not a date.

It is a decision about the maturity of the information being transferred - and the quality of every downstream decision that will rely upon it.

Architecture Needs to Name the Design Manager

 

Conceptual image generated using AI under author's direction

The familiar parable of the blind men and the elephant offers a useful way to understand contemporary project delivery. Consultants, architects, consent reviewers and contractors may each possess valid knowledge of the part they touch. The problem begins when no one is explicitly responsible for seeing how those parts relate. That whole-project view is the particular responsibility of the design manager.

If design management is essential to project delivery, why is it still treated as an informal responsibility?

The recurring all-nighter exposes more than a difficult deadline. It reveals the absence of clear responsibility for managing design decisions, information, interfaces and change. Architecture already relies on design management; it is time to recognise and name the role.

In my recent ArchitectureLive! article, The All-Nighter Is a Governance Failure, I argued that the recurring late night in an architectural office is rarely just a deadline problem.

It is often the visible end of something that began much earlier: an unsettled brief, a delayed appointment, an unrecorded decision, an unresolved interface, an unrealistic promise or a change whose consequences were never fully examined.

The architectural team eventually absorbs these accumulated uncertainties because the drawings become the place where everyone else’s information must agree. What appears to be a production crisis is frequently a governance failure.

But that diagnosis leads to another question.

If projects need someone to manage decisions, information, interfaces, change and design-stage readiness, why does architecture still struggle to recognise design management as a distinct professional role?

The responsibility exists even when the job title does not

Design management is already happening on almost every complex project. The problem is that it is often happening informally, partially or too late.

A project architect may maintain the consultant programme. A senior architect may chase client decisions. A BIM coordinator may identify clashes. A project manager may track deliverables. A technical lead may review compliance. A director may intervene when an issue becomes critical.

Each person is addressing part of the design-management problem, but no one may be explicitly responsible for seeing the design-delivery system as a whole.

That fragmentation matters.

When responsibility is distributed without clear ownership, gaps become difficult to see. The programme records when drawings are due but not whether the decisions required to complete them will be available. Consultant appointments identify disciplines but not always the interfaces between them. Design meetings generate discussion, but actions may not be linked to accountable owners, consequences and decision dates.

The project appears organised because it has meetings, programmes, models and reports. Yet its unresolved dependencies continue to accumulate beneath that visible administration.

Design management is not the existence of more project information. It is the disciplined conversion of that information into timely, coordinated and traceable decisions.

A design manager is not simply another name for a project manager

One reason the role remains poorly understood is that design management is frequently absorbed into adjacent job descriptions.

It is not the same as project management, although the two must work closely together. Project management typically governs the wider obligations of time, cost, procurement, contracts, stakeholders and delivery. Design management concentrates on whether the design itself is sufficiently defined, coordinated, reviewed and evidenced to move safely from one stage to the next.

It is not the same as BIM management. BIM provides a digital environment for creating, exchanging and coordinating information. Design management determines what information is required, why it is required, who must provide it, what decision it supports and whether the project is ready to rely on it.

It is not identical to the lead architect’s role. The lead architect may be responsible for design quality, architectural resolution and the integrity of the design intent. The design manager protects the conditions under which that intent can be translated across disciplines, approvals, procurement and construction.

Nor is design management simply technical coordination. Coordination is one of its central functions, but the role begins before clashes appear and continues after drawings are issued. It includes the structure of the brief, decision authority, stage deliverables, review gates, change control, interface ownership, risk escalation and the relationship between design maturity and project commitments.

The distinctions are not territorial. They are necessary because modern projects are too interconnected for critical responsibilities to remain implicit.

The role sits at the point where authority and information meet

Architecture now operates within dense networks of specialist knowledge.

A seemingly small change to a hotel room can affect the operator’s requirements, structure, fire strategy, accessibility, services, acoustics, finishes, procurement, cost and programme. A façade decision can alter waterproofing, energy performance, structural support, maintenance access and consenting evidence. A ceiling coordination issue may reveal not a drawing error but a chain of unresolved spatial and engineering decisions.

Someone must see those relationships before they become late-stage emergencies.

That is the design manager’s distinctive field of attention.

The design manager asks:

• Is the brief sufficiently resolved for the stage being entered?

• Are decision-makers identified, and do they understand when their decisions are required?

• What information must be available before a design package can be completed?

• Which interfaces carry the greatest delivery risk?

• Are changes being assessed for their downstream consequences?

• Has each discipline worked to a compatible level of design maturity?

• Is there adequate time for coordination, checking and approval before issue?

• Does the evidence support the project’s claim that the design is ready to proceed?

These are not administrative questions. They determine whether the design can survive the journey from intention to construction.

Design management should make uncertainty visible

A well-managed project is not one without uncertainty. Architecture cannot eliminate uncertainty, because design develops through iteration and projects respond to changing technical, commercial and human requirements.

The objective is to prevent uncertainty from becoming invisible.

An unresolved matter should have an owner, a required decision date and a clearly stated consequence. A change should be understood not only as an instruction but as an intervention in a connected system. A stage review should establish whether the project is ready to advance, rather than merely confirm that a scheduled date has arrived.

This is where design management differs from bureaucracy.

Bureaucracy can record that a meeting occurred. Design management asks whether the meeting produced the decisions the project needed.

Bureaucracy can list deliverables. Design management tests whether those deliverables are coordinated, sufficiently mature and suitable for their intended use.

Bureaucracy can circulate a change. Design management makes its effect on other disciplines, approvals, cost, programme and completed work visible.

The purpose is not to create more control for its own sake. It is to prevent creative and technical effort from being consumed by avoidable rework.

The profession needs a clearer job description

Many architectural employment structures still move from architect to senior architect, associate and director, with specialisation recognised mainly through design, technical or commercial leadership.

Design-management capability often sits between those categories. It may be expected from senior staff but neither explicitly defined nor adequately supported. On contractor- and client-side teams, the title is better established, although its scope can still vary widely. Within architectural practices, it is often mistaken for diary management, document control or meeting coordination.

That understates both the expertise and the authority the role requires.

A meaningful design-manager job description should include responsibility for:

• design-planning and information dependencies;

• brief and deliverable alignment;

• consultant scopes and interfaces;

• decision schedules and responsibility structures;

• design reviews and stage-readiness assessments;

• change-impact evaluation;

• coordination and technical-risk escalation;

• design-quality assurance across issue cycles;

• connections between design maturity, procurement and construction; and

• organisational learning from repeated delivery failures.

The role also needs sufficient authority to challenge an issue date, escalate an absent decision or identify that a design package is not ready. Accountability without authority merely creates another person who can be blamed after the event.

From an informal craft to a professional discipline

I have been developing these ideas through a wider body of work provisionally structured as a Design Manager’s Manual.

The purpose is not to reduce architecture to checklists or to suggest that every project can be controlled by a universal procedure. It is to articulate the recurring governance questions that arise across the life of a project—from the formation of the brief and appointments through design development, coordination, approvals, procurement, construction and eventual learning.

The emerging framework examines design delivery across successive project stages and treats it as a control loop: establish requirements, allocate responsibility, coordinate information, test readiness, record decisions, manage change, verify outcomes and carry lessons forward.

The manual is therefore less about prescribing one way to design and more about protecting the conditions required for good design to reach the built outcome.

Architecture already teaches design history, representation, technology, professional practice and construction. It now needs a more explicit understanding of design management: not as an inconvenience imposed after design, but as a discipline that connects design intent with collective delivery.

Better design management is not less architecture

Some resistance comes from the fear that naming this role will make architecture more managerial and less creative.

The opposite is more likely.

When architects spend their most valuable hours reconstructing decisions, locating missing information, correcting unmanaged changes or resolving interfaces that should have been addressed earlier, creativity is not being protected. It is being taxed by disorder.

Good design management does not decide what architecture must become. It ensures that the people responsible for designing it have a credible brief, coordinated inputs, visible constraints and enough time for judgement.

It also creates a fairer professional culture. Teams should not have to compensate through private sacrifice for risks that were visible at project level. If a deadline depends on unresolved decisions, inadequate resources or incomplete information, those conditions should be surfaced while leaders still have choices—not transferred silently to the people producing drawings at midnight.

Name the role before the next crisis

The design manager will not eliminate every difficult deadline. Unexpected site conditions, urgent approvals and genuine opportunities will still demand extraordinary effort.

The test is whether extraordinary effort remains extraordinary.

When late working becomes predictable, the profession should stop treating it as evidence of commitment and examine the system that made it necessary. That examination requires more than general calls for better communication. It needs a person with a defined responsibility to connect decisions, information, interfaces and design-stage readiness.

Architecture already relies on design management. It is time to stop treating it as an unnamed extra carried by whoever happens to notice the gap.

The recurring all-nighter tells us that the responsibility exists.

The next step is to recognise the discipline, define the authority and name the job.

---

This essay accompanies “The All-Nighter Is a Governance Failure,” published by ArchitectureLive! Read the original article here: [ARCHITECTURELIVE ARTICLE LINK].

Working Smart - 3

Search emails in Outlook 2016

Finding that elusive email from someone can become a life and death situation for us in Outlook. Multiple projects, client emails, and a swamped email box with 50+ emails received on a daily basis can be difficult to track. You know the mail was from X with an attachment but several emails over months make it impossible to zero down on the particular email especially if it was sent several months back

This version of Outlook can make your life easier if you are willing to spend some time reading this post. Follow the 9 easy steps below and you can quickly search for that elusive email

1. Open Outlook and go to your Inbox. Click your mouse on the “Search Current mailbox”.

2. The moment you click in the search bar, the cursor will start flashing in anticipation of your search

3. Your tab will change as per the screen above.4

4. Now go to the dropdown box as per the black arrow

5. The dropdown box should display all the fields you could possibly search from

6. Click on the fields you want and they will start stacking up below the search bar as you click on the fields. These will then drop down every time you put your cursor in the search bar - ready to aid you in a search.

7. Typically you would need the subject, cc, To, Attachments(Yes/No) and From.

8. You can also use Body which is quite useful when you want to search by a word in the body of the email.

9. This can be done in your “Sent” folder as well.

Work Smart and Happy Searching!

Also Read:

Working Smart - 1 Finding that Directory

Working Smart - 2 Save your files with a date

Working Smart - 2

Saving your files with a date

On an average, you would be creating and accessing at least 10-12 documents, spreadsheets etc. Soon there would be hundreds if not thousands of documents piling up in your directory with different file names. Accessing it alphabetically may be an option but prefer to name my documents with a yymmdd_filename format which lists the documents in the directory in a nice organised way starting with the most recent ones on the top.

When I create documents in such numbers, I often forget the name of the document which I have created. Sometimes, I don’t access a document for several weeks which removes it from the recent documents list of word and excel. That’s where I end up using the search function in the Windows explorer. Explorer searches all the directories and subdirectories and highlights all the filenames starting with the year and month - if you have been saving all your files starting with the yymmdd prefix.

Work Smart and share your experiences of Working smart.

Working Smart - 1 Find that Directory

Working Smart - 3 Find that email

Working Smart - 2

Saving your files with a date

On an average, you would be creating and accessing at least 10-12 documents, spreadsheets etc. Soon there would be hundreds if not thousands of documents piling up in your directory with different file names. Accessing it alphabetically may be an option but prefer to name my documents with a yymmdd_filename format which lists the documents in the directory in a nice organised way starting with the most recent ones on the top.

When I create documents in such numbers, I often forget the name of the document which I have created. Sometimes, I don’t access a document for several weeks which removes it from the recent documents list of word and excel. That’s where I end up using the search function in the Windows explorer. Explorer searches all the directories and subdirectories and highlights all the filenames starting with the year and month - if you have been saving all your files starting with the yymmdd prefix.

Work Smart and share your experiences of Working smart.

Working Smart - 1 Find that Directory

Working Smart - 3 Find that email

Working Smart - 1

Over the years as we have transitioned from a traditional workplace with physical files to the networked environment with information being stored virtually. With numerous people working on projects from multiple locations, information cannot be kept on individual machines and needs to be saved on servers. Information needs to be accessible instantly and to everyone.

Most companies have IT protocols in place instructing people of the do’s and don’ts. But rarely will you find tips about how to work smart and these posts are all about working smart and having information at your fingertips. 

Finding that directory

A large part of my work is to update the various documents, reports, and registers that need to be maintained in a Project Management environment. I prefer to use a shortcut on my desktop with the link to the directory saved and I am ready to go. 

This way, I access the correct folder every time and I do’t have to remember the long path to the directory.  which more often than not would be nested several levels below your project folder. These links can then be safely saved on your desktop. 

If you have too many links – create a word document on your desktop and use the function available in word to hyperlink to your directory/directories and you will panic less when you need that information quickly.

Work Smart and share your experiences about Working Smart

Also Read:
Working Smart - 2 Save your files with a date
Working Smart - 3 Find that email

10. Entertain the team with emails written in (im)proper English

Image courtesy rakratchada torsap / Freedigitalphotos.net

As the last post in the series 10 (un)common mistakes to avoid in Project Management, I conclude the series with this post. here are some lines extracted from emails written. The lines have not been modified and I will leave it to the reader to interpret some of the meanings. If this becomes impossible or if you end up doubling in laughter or both, go to the end of the post where I have put in some hints about the lines. I have highlighted the faux pas in bold and italics. Some of them are really priceless nuggets. Have fun

1. … let us give pleasure to the client …
   
2. I don't what you to advice or work on any problem......
   
3. If [Person] what any information from your end or what your input for any …...
   
4. Let's discusses in detail when we come there......
   
5. I thought much , now can a they say the submission is on [day of the week] . All the tender which you see in [Place], they is no fixed date for submission. Anyways we will submit the same on [Date] .
   
6. I don't what you to work on your …....
   
7. How whats the problem …...
   
8. we have haired him has [Designation]. I what him to do that...
   
9. he what's [Place] team to make a ….
   
10. I what this to be done before …..
    
11. they what Engineers full time....
    
12. Please advice , so that we don't what 100 idea in between. I what every one.....
    
13. Please note - Team is busy with Project can waste time in training every day. Let's do it once and close it asap.

Hints

• For the first one read pleasure as pressure
• Read what as want
• Now and how are interchangeable
• they and there are interchangeable

Links to the previous posts
9. Don’t govern by threats
8. Support the team on the Ground
7. Provide Mission Critical information to the Project Team
6. Resource appropriately
5. How to (not) do your budget in five easy steps
4. Read the contract you just signed
3. Don't promise the impossible in a ridiculous timeframe
2. How (not) to win a contract
1. New Business Areas

9. Don’t govern by threats

Image courtesy Stockimages / Freedigitalphotos.net

As a cherry on the cake, complete the circle by threatening employees by a variety of threats and bully them into submission. Completely politicise the working atmosphere by turning each employee against the other and follow through by asking each employee to “report” about the others privately. Although these may be stone age tactics, these are used effectively by managers in dealing with a new and superbly qualified professional team. 

International organisations world over recognise bullying to be detrimental to the work process. Some of the signs of bullying are :

• Micromanagement at all stages of the work process hamper the flow of the work and indirectly question the integrity of the employees. This effectively reduces an experienced employee to a rookie who needs to ask for instructions at every stage
• Intruding privacy with phone calls at odd hours and clear threats to answer emails received on hand held devices within minutes of receiving them. Not answering phone calls or emails would lead to a “dressing down” in front of other employees – another clear bullying tactic.
• Displaying intimidating behaviour about specific employees in front of other employees in their absence by threatening to fire them – incessantly and constantly.
• Constantly deflecting requests for personal time off which is contractually due to the employee thereby traumatising employees.

To top it all, none of these “rules” are available in the company rule book or available from the Human Resource department.  The employee has little or no choice but to fall in line with the bullying tactics of the boss. The employee can

• Establish ground rules and areas to allow the “micromanagement” to slowly metamorphose to a stage where it becomes redundant or even stupid
• Gradually and firmly, establish the limits of office time and private family time.
• For the intimidating behaviour, the employees could unite against such behaviour and stand up to the bully. After all, one can’t “fire” the team all at once.
• For the requests of leave, if it is clearly due and official, the employees should stand up for their rights. Eventually, the bully will back down.

In the tenth and concluding post, look forward to an entertaining piece on email writing. Links to the previous posts are below

8. Support the team on the Ground
7. Provide Mission Critical information to the Project Team
6. Resource appropriately
5. How to (not) do your budget in five easy steps
4. Read the contract you just signed
3. Don't promise the impossible in a ridiculous timeframe
2. How (not) to win a contract
1. New Business Areas

8. Support the team on the Ground

Image courtesy:  africa / Freedigitalphotos.net

Mistakes happen. Sometimes several of them at once or in a sequence. The team on the ground, under most circumstances at least has the strong support from the core team which is experienced and has encountered many such difficult project situations. Not So.
The core team is busy with other projects or is simply interested in churning out the monthly invoices to protect the bottom lines and manage salaries of the team. Support and advice in the form of a conference call can become difficult to organise.  In strictly hierchical firms, independent decisions by project teams are vigourously controlled where the project delivery becomes a risk.
Looking back at such situations, one could:

• Draw up clear protocols for raising project related issues all the way to the top of the hierarchy of the firm. Even top management including owners should remain accessible for project related issues. The access can of course be controlled and monitored so as to involve them in only crucial issues.
• Regular contact with the project team in forms of conference calls or meetings.
• If meetings or calls do not become possible, regular reports should be scrutinised and advice given for crucial, unanswered issues

In the next post, I shall be discussing the ninth point in the series – Don’t govern by threats.
Links to the previous posts
7. Provide Mission Critical information to the Project Team
6. Resource appropriately
5. How to (not) do your budget in five easy steps
4. Read the contract you just signed
3. Don't promise the impossible in a ridiculous timeframe
2. How (not) to win a contract
1. New Business Areas

7. Provide Mission critical information to the project team

Image courtesy Stuart Miles / Freedigitalphotos.net

After all the mistakes listed so far, an employee would definitely expect to start the project with all the critical and important information necessary for the project. Not likely. The team who has put together the project does not deem it necessary that the Project delivery team has all the critical information required for the timely delivery of the project. This is often due to lack of trust while passing on the information and mistaking the delivery team to be a an adversary rather than an important part of the project delivery process. When members of the team come from several different cultures, countries and time zones this often becomes a major problem to the delivery of the project.
Important milestones in the contracts are missed consistently because of this lack of communication. This affects the overall project delivery and in some serious cases this has led to the entire contract being terminated and the teams of the stakeholders entering into arbitration. This is a messy, time consuming affair which can be avoided.
Simply put,

• Communicate with your team about the key milestones of the projects
• Ensure that the team is “on the same page” and everyone is not following their own agendas.
• Communication protocols should be clearly established especially when teams from various nationalities, cultures, educational backgrounds and disparity of ages is coming together to deliver the projects in countries of the Middle East or Africa. This becomes critical when people are working across several time zones at once.

In the next post you can look forward to Support your team on the Ground.
Links to previous posts
6. Resource appropriately
5. How to (not) do your budget in five easy steps
4. Read the contract you just signed
3. Don't promise the impossible in a ridiculous timeframe
2. How (not) to win a contract
1. New Business Areas

6. Resource appropriately

To recruit the right person for the job is an an extremely rare expertise for companies to have in today’s fast paced world. A lucrative package with a fancy tag in an exotic sounding location sounds great but comes with its own pitfalls. By promising  a stable, lucrative position in today’s unstable job market, an employee is led to believe that past experience and expertise has helped him/her get the post but in all likelihood one is being set up by the employer. This becomes a necessity when all the mistakes listed in the past five posts have happened – either by conscious design or by an unnatural twist of fate.

While your employer may have signed a milestone based contract, they may have provided resources based on a timesheet based contract. Needless to say, resources that may be required at construction stage are not useful at early design stages. Construction Management resources adept at handling complex sites end up twiddling their thumbs while Design Coordination struggles due to lack of resources.

Several such situations like this may have arisen where such challenges in some form or the other present themselves to Project Managers. Under such situations, choices are limited to:

• Adapt to the challenge by accepting the situation as it unfolds in a new job situation
• Be pro active and raise a flag about the inadequacy and wrong type of resources which could potentially backfire.

A compilation of experiences on similar situations may add to our body of knowledge and will improve Project delivery to clients and modify our working methods.

Links to previous posts

5. How to (not) do your budget in five easy steps

4. Read the contract you just signed

3. Don't promise the impossible in a ridiculous timeframe

2. How (not) to win a contract

1. New Business Areas

5. How to (not) do your budget in five easy steps

Image courtesy patpitchaya / Freedigitalphotos.net

If you have reached to the point where you have to give the budget for your project after you have systematically made all the four mistakes listed previously, you are either plain lucky or a sitting duck. More likely the latter!
Here’s how to (not) do a budget. Imagine the scenario in the Post # 3. For that scenario, do the following:

1. Get the rates for a single house from a local contractor. Extrapolate the rates to 1500 houses. Simple
2. Cross check the rates against your home country rates. Rest in the comfort that they are much higher than your home country rates.
3. Ridicule all the advice by your own staff related to employing qualified Quantity surveyors by saying “That’s how we do it here.”
4. For the rates that are not available locally, use your home country rates, multiply them by some factor and build them up. Simple. Not rocket science is it?
5. Float your budget to the client

The fact that the project is the first of its kind in a less developed place, in a ridiculously impossible time frame, should not matter. Armed with this “budget” go ahead and float your tender to international contractors.
Obvious lessons from this post are

• Budgets prepared by such rudimentary methods can not be the basis to go to tender. This clearly misguides the client into believing a budget which will not stand the test when the bids come back.
• The Project Manager’s budget – if prepared at all, should not be shared as a Cost Plan document to the client.
• Do not hesitate to employ local professionals who will give you a correct picture of the rates and an accurate and reliable number.

Links to previous posts of this series
4. Read the contract you just signed
3. Don't promise the impossible in a ridiculous timeframe
2. How (not) to win a contract
1. New Business Areas

4. Read the Contract you just signed

Sounds strange? Impossible? Three out of four times? Chances are that the contract that you have been handed over to execute has not been read by the person who signed it.  

Unbelievable as it may sound pressures of time, lack of appropriate resources and a desire to grab the contract often lead to these situations. In the contract that has been signed for you to execute has all the deliverables in the world that the client could think of. Not to mention the ridiculous time frame in which to execute them. It would be an unfortunate situation if you have such a situation to deal with. Disastrous if this is the fourth in the series of mistakes that have happened and you happen to inherit the consequences.

Some lessons you could learn would be (Pardon me for stating the obvious)

• Read the contract (before signing it of course!) and iron out the kinks. Both parties entering into the contract have an unsaid right to review the contract before it gets to the signing stage.
• It does a lot of good to your company’s professional reputation if you suggest a few changes which may have been missed out inadvertently.
• Save on “fan cleaning” costs at  later.

The next in the series is about getting your budgets right.

Links to the posts in this series

3. Don't promise the impossible in a ridiculous time frame

2. How (not) to win a contract

1. New Business Areas

3. Don’t promise the impossible in a ridiculous time frame

Image courtesy chokphoto / Freedigitalphotos.net

The third post in the series 10 (un)common mistakes to in Project Management. Promising the impossible in a ridiculous time frame. Rome wasn’t built in a day. Or a month or even a year. Recently the new Doha airport has also opened after a year’s delay. At the time of signing the contract for the project, Business development teams promise the impossible leaving the delivery team to struggle with the difficult schedule.
Bear with me and imagine a scenario wherein a less developed place, isolated from the developed world where even the most basic building material - cement is imported. Prices of commodities are normally three times the world average cost. Skilled labour is not available.  The topography does not favour you either. Steep gradients and a richly undulating landscape with more than 100 inches of rainfall annually. Residents of the place build a house over several years with very rudimentary techniques and methods. The largest building contractor does not build more than a few dozen residential units in a year. In this kind of a scenario would you sign a contract to deliver 1500 building units designed by architects sitting 6000 km away with the best of modern materials and amenities in less than a year? If you answered yes then I’d like to hear from you.
Valuable lessons to learn from such uncommon incidents :

• Acquaint yourselves with the ground realities of a place for which you are going to sign the contract.
• It does not hurt to disagree with the client regarding aggressive (read impossible) time lines. In fact, he should be given correct professional advice at the right time.
• The time frames are not aggressive by themselves alone, they become a constraint when other circumstances are ignored.

I will be posting about a fourth uncommon mistake "Read your contract".
Links to previous posts in this series
2. How (not) to win a contract
1. New Business Areas

2. How (not) to win a contract

The second part in the series of “10 (un)common mistakes to avoid in Project Management”, is How (not) to win a Contract
The pressure to grow multifold, to get more revenue into the kitty prompts companies and business development executives to resort to "unconventional" means to procure projects.Most of us have encountered various unconventional methods used by the go getters of organisations who spare no effort in winning a project for the company.  During the initial stages of bidding for the project this often comes under the guise of agents who can "help" you to get a project. As a Business development executive this is an easy solution but you have only postponed the problem and successfully invited disaster for your Project Delivery team. Not to mention the strain it will create between you and the client as you start the project on the back foot because the client has the upper hand in this relationship. Not the best way to deliver a project. Other problems include a huge dent in your revenue as the agent is going to take away a huge chunk.
Valuable lessons to learn from such uncommon incidents :

• As a professional entity, disallow such practices at the highest levels as they are a surefire way to invite disaster. One project acquired in this fashion will wipe out the reputation earned from all your past projects. The industry in which you work is a small group and word travels fast.
• Emphasise on traditional values like honesty, integrity and hard work above all else – though they might sound archaic and old fashioned in today’s fast paced world.

"Don’t promise the impossible in a ridiculous time frame" is the third in the series. Read about the previous post here.
1. New Business Areas

10 (un)common mistakes to avoid in Project Management

Ten avoidable issues. Very basic, Simple and based on plain common sense but uncommon to find.

New Business areas

 Image courtesy of Renjith Krishnan / FreeDigitalPhotos.net

Success in one region or a particular discipline does not mean you can duplicate your success using the same formula in unknown regions and cultures. If you are an ace at managing and designing residential developments in the Middle east, does not automatically translate to a successful design of an airport project in a different culture and geographical region (and continent) like say South America. In the competitive world, such ventures give the age old adage "Fools rush in where angels fear to tread" a completely new meaning.
Perhaps pressure to grow into new areas pushes companies to venture into such new business areas.
Valuable lessons to learn from such uncommon incidents :

• Employ professionals who have extensive experience in the new areas and business verticals that the company wishes to venture into. Needless to say, these professionals should be trusted and groomed into the company culture.
• Recognise the differences in cultures and geographies which play a large role for new companies entering new geographies and business verticals.
• Recognise the fact that new geographies and business verticals have a gestational period and would take time to yield results and profits
• Recognise the fact that successful strategies and formulae of a hugely successful region and business vertical do not translate to the same success in other regions and cultures.

In the next post I will be posting about How (not) to win a contract 

Other posts in this series

9. Don’t govern by threats
8. Support the team on the Ground
7. Provide Mission Critical information to the Project Team
6. Resource appropriately
5. How to (not) do your budget in five easy steps
4. Read the contract you just signed
3. Don't promise the impossible in a ridiculous timeframe

.