How Projects Really Work

This is why you need System Engineers or System Thinkers…we help all these pieces come together, communicate, document, and succeed.    How Projects Really Work

How the customer explained it

My job is to listen to the customer.  I need to understand what they desire, why they desire it, and what they hope to get from what they want.  It is my job to translate those requirements into a workable project.

How the project leader understood it

All too often, the project lead, or task lead, or program manager, does not hear correctly, from the customer’s perspective.  There can be many reasons for this, but I think it comes from management driven-timelines, fixed budgets, and historical perspectives on how things should be done.  This obviously can set the stage for conflicting expectations between the project leader and the customer.  There is a trickle down effect that will skew all other stages of the project and lifecycle of the project.  I make sure what the customer wants is documented correctly.  I will save you time and money by overcoming this avoidable obstacle.

What the customer really needed

It is my job to help the customer find the most reasonable solution to a problem.  I use the expertise of my team to do this…in the end, what the customer really needed was something much simpler than originally thought.

How the analyst designed it

I facilitate communication between all elements of the project, from conception to refining desirements and requirements into workable solutions.  Those designing the system must understand how that system interacts with other elements or stakeholders.  This needs to be done early in the project, as fixing these types of common misunderstandings can be very costly and timely later down the lifecycle road.

How the programmer wrote it

I am not a computer programmer, but I do understand that we all have our own language in our specific fields of expertise.  It is my job to make sure the programmer, analyst, and customer speak the same language for the projects they work on together.  When the customer says two ropes tired around a tree, it is my job to make sure the programmer understands functionally what the customer needs.  This is an iterative process.  Again, if done early in the project the cost is minimal.  If done later, as you can see, you may have a system that is unusable, requires extensive repairs or reconfigurations, or simple will never meet the desired objectives of the customer.  This equals money and time or even a failed project.  I will help you avoid these.

How the project was documented

In my opinion, one of the greatest faults of almost all projects and programs.  Document, document, document! Documentation is our bible in systems engineering.  It helps ensure all stakeholders understand with common lingo what is going on, what will go on, what the limitations may be, what the budget will be, and where improvements can be made.  It provides milestones, defines deliverables, and sets expectations.  These documents become lessons learned and the basis for additional projects of similar background, processes, or requirements.  This is often time consuming, but will most definitely save the project and ensure customer satisfaction when products are delivered, if done correctly.







Business Development Analyst

I have been asked to describe the difference between ISO certification and Systems Engineering.

ISO certification is basically a process to ensure Quality.  ISO deals with the logistics of how a project/program/business is run.  It is used to show a strict process is employed to deliver quality products.

Systems Engineering is also a process, but not a strict process…SE requires creative thinking.  It is the process that helps ensure programs and projects are executed with all aspects of the latter understanding the requirements of the endeavor, communicating with each other, and documenting the progress.   While the process, soft systems methodology, is defined, as a creative Systems Engineer, you must employ those aspects of the methodology that suit the task at hand.  The goal is ensuring all stakeholders in a program, project, or business understand the desired end state, limitations, and deliverables.

As a Systems Engineer, you may wear several hats: Consultant to project manager, client liaison, facilitator for requirements and strategy development, recommendations for change management, and business development analyst.

ISO and SE walk hand in hand.  SE is used to help ensure quality AND customer satisfaction, under projected costs and time constraints.

Take 2: What I can do for your organization…

While researching jobs here in the Netherlands that I would consider “up my lane,” and after speaking with several professional contacts, I’ve decided to redirect my job search away from Systems Engineer to titles that are more commonly used here in Holland, yet accomplish the same tasks: Project Manager Consultant, Change Management Consultant, and Business Analyst.  All these functions cover my training and the functions of a Systems Engineer.

Now, the challenge is to find those positions, and the people hiring for those positions, to explain the added benefit I will bring to those tasks as a Systems Engineer (a term not well understood in the Netherlands outside of computer systems).   This includes an understanding that you want ME at the beginning of development to reduce costs and delivery times!

Once again, I am not a computer systems engineer, I am a complex system analyzer who applies a defined methodology that helps organizations understand the system requirements, limitations, resources required to change or develop, and timelines associated with all these steps.

There are many objectives to applying this methodology: managing stakeholder expectations, facilitating development of solutions to complex problems associated with the projects, and keeping the project management under cost and on time!

In short (thanks University of Minnesota for explaining it so concisely!)

“The purpose of a systems engineering approach to project management is to produce systems that satisfy stakeholder needs, increase the probability of success, reduce risk, and reduce total-life-cycle cost. It focuses on defining customer and other stakeholder needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system verification and validation.”

What I can do for your organization

After being presented with the task, I will:

  1. Research and analyze the culture/mission of the organization(s) developing the system/project in order to clearly define the system/project boundaries, objectives, limitations, etc.
  2. Apply a systems engineering project management process that is reproducible and has defined milestones.
  3. Educate all stakeholders on system engineering principles and the importance of this project management process.
  4. Ensure project has documented requirements management and integration of reliability, maintainability, and supportability into systems design/project development.
  5. Help develop system development or project execution teams that have skills necessary to identify systems engineering technical processes, including stakeholder requirements, functional analysis, architectural design, integration, verification, validation, and total life-cycle considerations.

This is a simple break-down, but hopefully more clear for my target audience here in Holland.  Click here for a readable link to the graphic.

Thanks for following me and keep the comments and suggestions coming!

Dear Hiring Manager:

After contributing to the rapid growth and success of several high-profile organizations within the United States for over 15 years, I am actively seeking a new, challenging career-oriented position in the Netherlands.  I seek a position that capitalizes on my unique skill-set and professional experience in directing successful teams and projects, and requires strategic planning.  In addition, I am competent to lead and carry out all phases of project management, from study design through field supervision and data analysis.

My process for finding my dream job in Amsterdam

Looking for a job in another country is challenging for a few reasons.

First, job searching is easier when you know the job board sites.  In the States, you know exactly where to look:,,, etc.  I basically knew what I was looking for, too…I understood the job titles: Researcher, Biologist, Intelligence Analyst, etc.  Not so much in another language, especially when you are still learning it!

Second, even though systems engineers are highly associated with the IT profession globally, in the States there is more of a push for non-IT related systems engineering.  In all of my professional careers, non-IT related systems engineering was essential.  We must define our stakeholders, common terms, project timelines and resources, constraints, expected outcomes, milestones, etc.  It seems in Holland, Business Analyst, Strategic Analyst, and Process Engineer (to name a few) are more common job titles than Systems Engineer, to meet these objectives.

Finally, as I expand my professional network here, I am finding more blogs and tweets discussing the international muddling of the title Systems Engineer, and the oft-times confusing mixing of the phrase with IT.

These are some of the reasons my search for the dream job is challenging.

So here’s what I’m doing now to help myself find the dream systems engineering job in Holland:

  1. Defining what I do or the value I bring to an organization here in the Netherlands.
  2. Researching think tanks and other companies in Holland that work in those areas I know and would enjoy continuing my career with – then following them and their blogs/posts/tweets/etc.
  3. Refining my job search by communicating with other systems engineers and LinkedIn contacts to fortify my understanding of how systems engineers are utilized here and specific job titles they hold.
  4. Requesting referral interviews from my professional contacts on LinkedIn.  Asking if they know someone I could talk to that would help me understand those organizational needs of companies I want to work for, and to help me define how I can meet the needs of those companies.
  5. Get my message out to those who can pass it along!  TWEET TWEET!!  Tweeting about my blog and re-tweeting my contacts posts…helping others get their messages out…fingers crossed, they are doing the same for me!
  6. Constantly refining my message: who am I and what do I want to do?

Lots of reflection is required to figure out what I want to do.  But this reflection helps me (and my partner) be patient with the process.  Right now, this is my full-time job.

It has been a few weeks since I arrived in Hoofddorp.  I find Holland an amazing place! I love the people, food, landscape, and culture – and this will help me in the long run.  Albeit slowly, I am also learning to speak Dutch.  And while I want a job now, on the positive side, I have some breathing room to learn Dutch customs and personal interactions – which will help me integrate professionally into Holland.

I hope to report soon all about my new job.  Until then, please keep the feedback coming!


A Good Systems Engineer

It amazes me how so many program/project managers assume about definitions, which directly impact stakeholder expectations (which may also have different definitions for the same words). A good systems engineer must have the ability to communicate in the language of all its stakeholders, develop common terms, support relationships between different stakeholders with, most likely, different business goals, in order to propose acceptable solutions to complex problems with multiple stakeholders. Also, a good systems engineer needs to understand the culture of the organizations it is dealing with (both professional and actual location in the world). Many people do not have a true understanding of SE, or SSE, so we have to find ways to speak their language while actually doing our intended jobs.

One of the best systems engineering talks I’ve seen


What Is Systems Engineering? A Consensus of Senior Systems Engineers

Here is a great synopsis of Systems Engineering from A. Terry Bahill (Systems and Industrial Engineering at University of Arizona) and Frank F. Dean (Sandia National Laboratories  in Albuquerque, NM)

Systems Engineering is an interdisciplinary process that ensures that the customer’s needs are satisfied throughout a system’s entire life cycle. This process is comprised of the following seven tasks.

  1. State the problem. Stating the problem is the most important systems engineering task. It entails identifying customers, understanding customer needs, establishing the need for change, discovering requirements and defining system functions.
  2. Investigate alternatives. Alternatives are investigated and evaluated based on performance, cost and risk.
  3. Model the system. Running models clarifies requirements, reveals bottlenecks and fragmented activities, reduces cost and exposes duplication of efforts.
  4. Integrate. Integration means designing interfaces and bringing system elements together so they work as a whole. This requires extensive communication and coordination.
  5. Launch the system. Launching the system means running the system and producing outputs — making the system do what it was intended to do.
  6. Assess performance. Performance is assessed using evaluation criteria, technical performance measures and measures — measurement is the key. If you cannot measure it, you cannot control it. If you cannot control it, you cannot improve it.
  7. Re-evaluation. Re-evaluation should be a continual and iterative process with many parallel loops.


Additional Information

I appreciate all the feedback!  You asked me to add a few more things:

  • When am I available to work?   I am available NOW to work for you here in the Amsterdam area!
  • What type of work did you actually do on your completed projects?  I have added some more information on the Completed Projects page.  This information will give you an idea of the types of work I performed on those projects.
  • What did you study?  I have added some more information under Education to help the reader understand my areas of study.
  • Do you have working papers? Yes!

Keep the comments coming and I will keep making this personal branding site better!

What is a system engineer?

I do not develop computer systems.  I am not an information technologist!

What is Systems Engineering?

Systems Engineering is a fairly new field.

In short, using a Soft Systems Methodology (SSM), I analyze complex problem(s).  These complex problems usually involve multiple types of systems (technology and human) – and have multiple stakeholders with differing systems’ goals and requirements.

Through research and interaction with the stakeholders, I identify and define

  • the system boundaries;
  • the active and passive stakeholders;
  • the factors (external, internal, environmental) impacting the system.

With this information, we begin assessing system gaps and developing potential solutions to the problem.

Solutions may include

  • recommendations to stakeholders for addressing system gaps;
  • recommendations to stakeholders for optimizing existing system(s) or component(s) of the system (sometimes a system within a group of systems or System of Systems);
  • and/or recommendations about developing a new system to address the need(s).

I work closely with project managers to help manage client expectations, reduce project costs and timelines, and facilitate system development through from conception to execution.

A good resource for Systems Engineering is INCOSE, the International Council on Systems Engineering.

Next time I’ll talk more on SSM!

%d bloggers like this: