Skip to main content

Author: Efthalia Sismanis

Things I Learned (or Didn’t) by Managing a Real Estate Project

One thing I’m certain of as a Project Manager… nothing is outside the realm of my responsibility. The thing I enjoy most about Project Management is it gives you a chance to work on different types of projects, different applications and constantly find creative & efficient ways to get things done. There are times however, when you find yourself doing things you’d never thought you’d ever do.

“Facilities Manager” wasn’t a job I ever saw myself doing but it turns out, it isn’t all that different than being a Project Manager; you have to be organized, detail oriented and collaborate with a variety of people on a variety of issues on a daily basis. Clear communication is key and you need to stay on top of all tasks and dependencies. The old adage that’s true in Project Management is very true in Facilities Management – “it takes a lot of effort to make something look easy”.

I can’t say my stint as a Facilities Manager was a success. But after having had the opportunity to be involved in 2 real estate projects, I’ve learned a lot and I recommend that all software development Project Manager’s take on a Real Estate project, if given the chance. Here are some of my key lessons learned:

1. Real Estate projects make it easy to understand the need for proper planning;

Plan the work, and work the plan….it’s a part of every Introduction to Project Management course…and yet, in software development we ignore the simple rules of proper planning;

  • We proceed head first into execution, without completing and signing off on thorough requirements
  • We start engaging development teams and solutioning before we have an approved project and budget
  • We set deliverable dates without mapping out the appropriate tasks, durations and dependencies.

We pay the price for these ‘time-saving’ strategies. The price is in:

  • The Project Change Requests that have to raise, often through the deep & late stages of the project (or post-launch), for “missed requirements”;
  • The re-work during the Testing phase to “correct” the assumptions that weren’t validated;
  • In the number of Post-Implementation “defects”, because the project didn’t actually meet the business needs it was supposed to solve for

2. Real Estate projects clearly identify proper sequencing;

Think of your home – you cannot build the walls without a foundation; you can’t install the windows without walls, can’t lay down carpeting without a floor, and so on… look around your own home and it makes sense, doesn’t it ? You’re thinking, “I don’t need to lead a real estate project to know this” – and you are right. It’s not rocket science, and yet, in software development, we ignore the simple rules of proper sequencing;

  • We don’t create task-level plans with proper sequencing;
  • We don’t review these tasks with our teams and make them accountable for the information they provide;
  • We don’t get updates on each task – we concentrate only on higher-level tasks – like phase milestones;
  • We ‘overlap’ tasks and whole phases to save time or to recover from a delay on a task (or tasks) that we didn’t call out as requiring to be done.

We pay the price for not identifying sequential tasks properly because inevitably, when one task is delayed, it has multiple impacts and requires more re-work than having done the work in a proper sequence initially. You’re thinking, “who actually follows a proper Waterfall Methodology” ? And, once again, you are right However, if you’re going to cut corners, you need to understand the impacts of those corners and choose your corners wisely – without properly mapping out the tasks in proper sequential order before cutting those corners, the Critical Path will not be clear and costly mistakes will be made.

3. Real Estate projects make it easy to identify & communicate project impacts…on an ongoing and consistent basis;

If the brick delivery is late, the brick-layers can’t work, if the brick-layers can’t work, walls don’t get finished. If walls don’t get finished, the interior work can’t start, etc. Budget and time is lost as workers wait around with nothing to do. Overtime may now be needed to get the brick laid on schedule. Again, not difficult to understand, However, once again, we have a difficult time articulating the impacts of tasks that are on the Critical Path in software Projects because, we don’t ask. Even with the tasks laid out and the proper sequence and dependencies (including “cutting corners’), it’s easy to fool ourselves into believing that the impacts are only what’s on our project plan. If you’re the PM who spends most of their day updating your project plan/schedule, then this may work for you . If you’re like most of us, however you get to update your project plan maybe once a week, after all your other various responsibilities as a PM are baked into your day 

Your project plan can give you information on what tasks may be impacted, but it cannot articulate the impacts of those tasks. If specifications are late, file layouts cannot be completed; If file layouts cannot be completed, the build cannot start. If the build cannot start, then……etc.

What does this all mean?

Does it mean there is a resource constraint once the specifications finally arrive? OR that the resource that would have worked on this 2 weeks ago, is now re-assigned to another project, therefore the resource we get now has less experience? OR Is there other work that can go ahead for other specifications that are complete or work on something that doesn’t need a specification? Is there an impact to other projects, if you’re sharing resources (and these days who isn’t)? Is there a schedule crunch that requires mitigation?

The project plan will tell where you need to look more closely and will continue to do so, if you keep it updated on a regular basis A Project Manager needs to ask questions of many stakeholders to understand what the information means.

The only certainty is that plans will change, some tasks will run early, many will run late; and if you understad what it means, you’re able to manage the high-impact tasks effectively and spend the appropriate amount of effort on low-impacting tasks; you’re able to communicate appropriately to stakeholders and escalate the key risks before a risk becomes an issue.

4. Real Estate projects make it easy to see you need to get everything lined up before you start the work;

  • You can’t lay a foundation without permits, contractors, workers, equipment;
  • In order to get permits, paperwork must be completed, reviewed and approved;
  • To get contractors, contracts and agreements must be signed;
  • To get workers on the site and equipment, funds must be allocated.

Once again, it makes sense, BUT how many times do we;

  • Start a project without all of the right stakeholders on board for requirements?
  • Kick off a project and go all the way into design and build stages, assuming a vendor or partner will be on board by the test phase?
  • Install code for a vendor that doesn’t have a signed contract?

How do we pay the price for our sourcing “foreshadowing”?

  • We engage teams at later phases and required change requests for the “new” requirements that result from finally speaking details with the vendor.
  • We end up making assumptions about file layouts and interface connectivity that we inevitably need to modify in the test phase when things do not work.
  • We install code that our business teams cannot use for weeks, months – sometimes never– resulting in waste effort & expenses that could have been allocated better elsewhere.

So, what do we do?

We don’t deliver real estate projects, but we can use the Lessons Learned and leverage them to our advantage. While software is not the same as building a house, there is an inevitable sequence of events and tasks that need to be followed to ensure a quality delivery.

In order to execute well, we need a good project schedule/plan, which requires that we (along with our project teams and stakeholders) put in the effort to build the plan.

Our job as a PM is to deliver within our constraints; budget, scope, quality. To do so, we need to use the full PM skill set starting with the planning and controlling tools as they set the groundwork to allow us to effectively perform the other more interesting aspects; communication, influence, risk & issue management, financial management, vendor management, business readiness and the countless other details to manage our project.

After all, the fun of being a PM, is not really knowing what we will end up doing to deliver our project. By planning well from the beginning and refining the project plan throughout the lifetime of the project, and on a regular basis, we will reduce our and our teams’ stress points and allow us to do tasks we never thought we’d have to do.

Don`t forget to leave your comments below.