As a consultant, whether you're acting as a PM or otherwise part of the project team, it's your job to assure scope and effort are monitored. It's not always the responsibility of the project lead, or PM, to assure that tasks' hours are kept in check. Everyone contributes, and must participate in the regular evaluation of the spent budget and work remaining. The PM is absolutely accountable for the spend, but the project team is responsible for the spend.
In a public sector, the PM has to use extra caution because typically these funds are closely monitored and controlled by governing bodies. It's not always easy to generate a change order and there must be thoughtful audit trails applied to assure that these forks in the road can be addressed. It's not the fault of the consultant that change occurs, nor is it the fault of the customer. These things happen, and must be jointly observed, evaluated, and defined before such a path is selected.
In my experiences, the safest and cleanest way to assure minimal ambiguity around such scope changes is by way of a very complete and well constructed statement of work (SOW). You cannot assume that scope will work itself out in the project charter or by way of evaluation of each and every change instance; there must be clear boundaries applied at the contractual level to assure you have the means to keep a project's spend minimal, or at best "whole".
As I've preached for years, a good PM is also a very good legal writer. Whether he/she writes the SOW or works with account management to write the SOW, the PM cannot be absent of involvement here. After all, who's going to use this document? You are, the PM!! If I am going to asked to manage a project, I sure better be working closely with Sales/Acct Mgt to assure that it gets crafted in such a manner that I can definitively work within it to manage the project...
For instance, if we say that there will be requirements gathered from the user population by visiting several sites and that these requirements will define the design, and thereby implementation of such a solution to support all of those requirements inside the body of one SOW and around one cost structure, we're opening ourselves up for unplanned work, and most likely effort that exceeds estimates when dealing with a fixed price gig.
Working the customer to help them understand the project's structure, selecting a path to enlightenment, and assuring that there is sound evidence of this path, expectations, and boundaries living within the SOW, sounds like extra work. But, it will only make both parties satisfied because it will be clear that there is a vast unknown of requirements to gather. Out of these requirements, the customer can prioritize and select those requirements to go after and produce a design to support them. With a solid design and architecture, then the team can go about building it and the project spend has a far better probability of staying whole.
2010-12-20
2010-12-17
SOA what?? Part I
Been a while since posting to my blog...whow knows what SOA is? I can tell you that's it's a powerful set of methodologies that serve many benefits. Most obvious is the way in which information can be exposed and avaialble for consumption, consumption far beyond just storing data, but building solutions that integrate with this data sharing concept in the cloud.
Exchanging data, or the concept of the data exchange, is a very cool way of making your data available; in turn, a consumer of this data can do something useful (write an app that uses this data to solve a business imperative, for example) with it or simply be a subscriber of it.
The interesting dilemma for an organization today is not in the creation of such a data exchange - this is the rather simple part of hte equation. We can stand up data exchanges all day long that expose information - albeit, there is a tremendous need for clean data, so the backend must be able to support this or some large data scrubbing effort is probably needed. The difficult part is writing or extending a client solution to consume this data and do something useful with it - the "work". Understanding business processes in that client organization and how this newly exposed information can be used to solve them requires time and money. It's ever apparent that most organizations simply do not have existing records, documentation, goals, and needs well documented to understand where in the current processes these calls to the data exchanges could/should be made in order to solve the business problem. This is where the bulk of the effort and work lies, and this is where a skilled team is needed to consult and help strategize the how/where/when/why's of hooking up to a data exchange. This requires business analysis, domain expertise, data architects, and tight inclusion of those stakeholders exposing the data to the exchange and those stakeholders expecting to utilize this data to do work.
Moreover, think of the complexities involved. We need to determine the granularity of such an exchange - to what degree is a business capability exposed - is it super granular such that the message interface (xml) is very narrow allowing getting minute pieces of that data structure (age, birthdate, last violation, etc) or do we provide an aggregated exchange, but also bloat the size of the message interface. Here, we could establish a capability to Add a Debt Collection. This could involve associating a person, a debt type, a payment type, a debt amount, etc.
Summary for now...a data exchange is a good exmample of the SOA software strategy, but it requires much work during planning of the data to be exchanged, but most importantly, requires tight integration with consumers of such data structures and even more so a deep understanding of how current or future solutions need to be written to successfully consume these exchanges - pushing work out to the cloud, while also utilizing this data to solve business problems.
...so what does SOA really mean? More on that later...still unsure what the acronym stands for? Ok, it means Service Oriented Architecture. Come back for more discussion.
Exchanging data, or the concept of the data exchange, is a very cool way of making your data available; in turn, a consumer of this data can do something useful (write an app that uses this data to solve a business imperative, for example) with it or simply be a subscriber of it.
The interesting dilemma for an organization today is not in the creation of such a data exchange - this is the rather simple part of hte equation. We can stand up data exchanges all day long that expose information - albeit, there is a tremendous need for clean data, so the backend must be able to support this or some large data scrubbing effort is probably needed. The difficult part is writing or extending a client solution to consume this data and do something useful with it - the "work". Understanding business processes in that client organization and how this newly exposed information can be used to solve them requires time and money. It's ever apparent that most organizations simply do not have existing records, documentation, goals, and needs well documented to understand where in the current processes these calls to the data exchanges could/should be made in order to solve the business problem. This is where the bulk of the effort and work lies, and this is where a skilled team is needed to consult and help strategize the how/where/when/why's of hooking up to a data exchange. This requires business analysis, domain expertise, data architects, and tight inclusion of those stakeholders exposing the data to the exchange and those stakeholders expecting to utilize this data to do work.
Moreover, think of the complexities involved. We need to determine the granularity of such an exchange - to what degree is a business capability exposed - is it super granular such that the message interface (xml) is very narrow allowing getting minute pieces of that data structure (age, birthdate, last violation, etc) or do we provide an aggregated exchange, but also bloat the size of the message interface. Here, we could establish a capability to Add a Debt Collection. This could involve associating a person, a debt type, a payment type, a debt amount, etc.
Summary for now...a data exchange is a good exmample of the SOA software strategy, but it requires much work during planning of the data to be exchanged, but most importantly, requires tight integration with consumers of such data structures and even more so a deep understanding of how current or future solutions need to be written to successfully consume these exchanges - pushing work out to the cloud, while also utilizing this data to solve business problems.
...so what does SOA really mean? More on that later...still unsure what the acronym stands for? Ok, it means Service Oriented Architecture. Come back for more discussion.
Subscribe to:
Posts (Atom)