Raise your hand if your project planner types or copy-pastes every project milestone and phase into the project planning tool. If you have your hand in the air, I have a question: Why? Another question: How many times have project team members claimed that stakeholders were causing feature creep, or sales oversold capability?
Starting off a post-collegiate career principally in development, it was easy to be somewhat dismissive of the role that sales and business stakeholders played in the cultivation and evolution of a project. That naivety gave way to appreciation as I began to spend more time on pre-sales and roadmap-planning discussions. If you don't appreciate the sales department, get downsized a few times and see if your opinion changes. There's a whole domain of information related to the sales and roadmap-planning discussions that rarely finds its way into the project plans. That information is usually kept separate in a Customer Relationship Management (CRM) system or roadmap planning tool, and is used for lead generation, budget and commission tracking, etc. Some information from these systems, such as project milestones, schedules, roles, and estimates are shared, usually by printing or emailing a copy and then copying those values into another planning tool. Those two systems include the milestones and deliverables that sales is tracking with the customer from an account management perspective, and the roadmap that business leaders and stakeholders are using to guide and track progress against long term objectives. These are the project milestones, and they should be defined at a source. Consider the "Roadmap" diagram. At a high level, it appears too simple to be of much use. Nonetheless, these are the cornerstones of a project plan. It's what the customer and business were sold. Depending on the type of business and engagement, sales may influence the roadmap by defining customer feature requests, or in the case of vendors, by contributing the stakes. The corporate roadmap defines the goals for the next year or years, with projected budgets. Project teams may not see all of this information now (such as the budget), but that does not mean the information cannot still be directly related to project plans.
Time and money are the inputs into most project management models, such as the classic triangle or diamond. Those pesky customers and business stakeholders like to think in those abstract concepts of time and money. Why should a project plan factor in how much time the whole affair takes if its activities do not represent the whole, or the time and money components include non-project related work? Believe it or not, time and money are not infinite reserves, and even if an organization has a fixed budget with a use-it-or-lose it guideline, keeping a project plan disconnected from the roadmap and sales information results in feature creep and compressed schedules. If sales are compensated by net revenue, and business leaders are compensated by achieving those goals on time, on budget, or sometimes both, then it behooves the entire team to collaborate, which may seem counterintuitive when project teams usually don't want or need to consider those factors. Doing so helps everyone pin project plans against communicated milestones and schedules, versus a copy-pasted version, and then trying to squeeze the plan into those constraints.
Does this sound familiar: How long will it take you to do some work? It has to be done by this date, and it can't cost more than that amount, and it has to include these features. Give a project team such boundaries and they'll add fifty stakes (called assumptions) and a hundred reasons (called risks) to explain the snake-oil recipe needed to make this happen. Cue the random comparison to a fantasy or battle. Everyone laughs. Sales and business leaders are not amused.
Eventually, everyone gets down to brass tacks and the business and technical leaders are tasked with coming up with a high level plan. What will it take to get to the goal? More hardware? Virtual environments won't run without available resources. And IT has to work some networking magic. Add in some gap analysis and requirements gathering. Don't forget the design work. This is going to take a whole lot of design work. The architecture team will get back in a couple weeks to define how long the design will take. At some point in the overstuffed version of the plan, someone proposes: Can we do all this in parallel? Sure thing! Dependency analysis is needed. Oh, and by the way, the project team is Agile, except IT hasn't figured out how to iteratively upgrade the hardware for the virtual infrastructure, so the project methodology will be Agile-fall with automated testing all around. When the kickoff meeting ends, there's an initial push to get that first plan back, where it languishes for a while until, one day, the time comes to execute it.
And that plan, more likely than not, is a complete fantasy. The dependencies become unreasonable or are unattainable, and the goal everyone is working towards looks nothing like the actual goal. Sure, it may be written down the same way, but the journey being taken will lead to a different destination. Somebody, somewhere, is going to pull the emergency break and the project plan then either has to be rewritten, or all the hard misdirected work becomes shelfware. The reason? Because the goal everyone was running to was "The One Ring", taken there by the myriad activities that didn't correlate back to the original requirements. Even the twisted fantasy version of the project plan the team wound up running with was never right because the one ring should have started at Bag End anyway. However, the message back up to the stakeholders and/or customer gets massaged in such a way that everything looks fine on paper.
In a reasonably sized organization, projects with multiple teams will have mixed project methodologies, and both hard and soft dependencies that dictate when activities may run in parallel, and when they can't. However the project is run, and it shouldn't matter how so long as the method is efficient and effective, then pinning the project directly to the stakes and goals defined by the leadership team makes it apparent whether and how the project is falling off track. Likewise, separating efforts by methodology, but keeping the dependencies intact, allows teams to operate independently and more efficiently, while also tracking progress of those dependencies. How are these cross-project dependencies tracked in practice? Either by adding unlinked records into the project plan, tracking the cross-methodology work items in one plan, or writing two separate plans. Schedules, which define the time frames in which work needs to take place, may be attached independently to the projects and project phases. Therefore, the impact of something like the late delivery of a hardware purchase is an actionable event to other project teams as well as stakeholders, all the way up to the customers and business leaders. While arguments may be made that such details are not always pertinent, the influence of those details are pertinent. If that warning is not acknowledged, it gets swept under the rug and it falls on the dependent projects to make up the difference. This leads to conversations that begin with: "Why are we behind schedule?" which translates into "Why are you behind schedule?", and which really means, "My milestones aren't being reached, and why am I only finding out about this now?" At this point, the person in the hot seat will either shift blame, or refer back to the various risk and assumption communications; what's commonly referred to as CYA mode. However, the issue is more insidious than a late dependency wrecking a project further down the line. A contributing factor is what type of information is being captured by plans in the first place, and what an organization is even willing to track.
This situation can be avoided by making sure the unmanaged message, the unvarnished truth, is made clear straight up the stakeholders and then pinned there so the issue can be prioritized and dealt with. Sending an email does not count, nor does making a phone call. That ugly status must find its way back into the same place the milestone was initially set. If the reaction is to manage the message until the issue goes away, because the board or executives won't react well (or whatever the reason), then the remainder of the plan is a fantasy. If you're in the mood to read fantasy, I highly suggest this one.
Here's an exercise: Add up all of the time spent planning to plan the project plan, including all meetings, conference calls, roadmap work, analysis, and any other work needed to be complete before actually writing the project plan. Is all of that time included in the project plan? Probably not, because, as the typical response goes, the plan is for pending work, while those meetings were just pre-planning work. Well, I have a word for that, and that word is - you thought I was going to write waste, didn't you? No, it's overhead. It's work that needed to be done to get the project started. This includes all of the sales and accounting related discussions, all of the executive and board meetings, the phone calls, the emails, the proofs of concept, and everything else. Why isn't this being tracked? "They are never going to record their task hours," is one response I've heard. And, "We don't track capex unrelated to actual project work." I've heard a lot of reasons why not. And I don't agree with any of them. I think the time spent in the meeting between the architects and CTO needs to be tracked, the time the PM and stakeholders spent fleshing out business requirements needs to be tracked, and the time spent getting all of these materials ready to start a project plan needs to be tracked, and all of the time spent in meetings needs to be tracked. Why? Because all of those represent time and money invested in the project, ostensibly for a good reason. That is also time and money spent from a budget, either by cannibalizing another project, or from that general slush fund called payroll. If there is a good reason to do that work, then it's worth tracking as overhead. Otherwise, it's waste.
Overhead and waste can be expressed in terms of a project plan by identifying the module (or assembly) that a project produces, associated with a stake and goal, and by identifying task artifacts and dependencies. A task that does not satisfy a dependency, or does not produce an artifact, is waste. A project that is not associated with a stake or goal, or does not produce a module that satisfies a deliverable or dependency is also waste. There seems to be an aversion to tracking time and money spent prior to tasks articulated in a project plan, even though time and money are the key inputs into the plan. If those values are not tracked, then it's less likely that the project plan, or even the roadmap, will be more than bad fiction if the first action is to ignore the sometimes sizable effort required to create the plans needed to achieve the specified goals.
Finished adding up all the time spent getting read to write the project plan? Good. Now, make a quick little project plan out of those activities and lump them into two groups: Group A is everything used to create the project plan, and Group B is everything else. Group A is overhead, and Group B is waste.
One more exercise you can practice in your next meeting. Count the number of people in the room and on the conference call, and multiple that number by the average hourly rate for your industry. Be sure to include taxes and benefits. For example, fifty USD per hour. If there are ten people present for a one hour meeting, that's five-hundred dollars of money, and ten person hours. Then, that twenty minute follow-up discussion at the wipe board with half the attendees, is another eighty dollars and hour and forty minutes consumed. The ten and twenty minute ad-hoc discussions, which often times are very valuable, still add up over time and contribute to either overhead or waste. The differentiating factor is whether or not it produced something that is ultimately used to reach the goal.
Not tracking the overhead cannibalizes the resources from the project because the teams wind up working towards the same goal with less time and money than budgeted. And the gaps between actual time and actual cost lead to all sorts of problems later on: Condensed schedules, project rework, and budget shortages, and schedule slips.
The efficiency of a project plan can be improved by directly connecting the goals with roadmap milestones, capturing preparation work as overhead, and then by defining the work product at a task level to classify waste.
Here's an exercise for tech workers: What process must you (or do you) take to schedule, approve, plan, design, build, test, and release the following: A text change to a compiled resource. How many people are involved? How much time would it take? Go one, add it all up. I'll wait. All done? I like this exercise because the answers are both defensible and ridiculous. There's a reason for the people and process involved, and this one type of change should engage most if not all of the people and teams. One of the first times I did this, the answer was astounding: Eight people and twenty four work hours. As a consultant, I've had the opportunity to ask this question to many different organizations, and, for better or worse, it didn't get much better. So, the next question is: Why? Doesn't this seem wasteful?
It does to me. I grew so frustrated with rewriting the same project schedules to accommodate methodology nuances that I tried to figure out a better way. Rocket is my attempt at finding out where the waste is in the process (E.G.: via Theory of Constraints). This article introduces the Rocket platform. By way of introduction, here's a concept drawing of the Rocket entity community: Assets, Business, Processes, and Projects. And, let's get one item out of the way: Rocket represents complicated project relationships and dependencies across multiple organization segments; it is not intended to be a variation of Microsoft Project, or mimic online project management tools. There are legions of people and truckloads of money dedicated to making those products work, and they do a good job. Then again, if you find yourself wondering if you're just wasting your time, well, wouldn't it be nice to know where it's being wasted?
Another exercise for everyone currently working on project-oriented work: Where are the business requirements written down? And the technical requirements? And the use cases? Architectural drawings? All on the wiki, some say? Well, bully for those who do, but I suspect a fair number exist in separate documents. Do they exist relative to any project plan? Probably not. Now, if those items can be considered digital assets to the project plan, how was the plan created from them?
Thinking of requirements as an asset, as something that isn't only useful for reference, but something that can directly feed and drive a project, can increase the practical usefulness of the plan. Besides requirements, what other assets, digital or otherwise, are available? Time, money, people, documentation, prior design work, support tickets, bugs - just about anything you'd need to start. You may not actually get all or any of those things, but it's a place to start. There's a fount of information lying around, usually in a format that doesn't really help. What if that information was put to work? While there may be preference to do designs and proof of concept work without first taking stock of what's presently available, doing so adds risk of duplicating work or embarking on an effort that could never work within current constraints. This is a pretty big challenge because many people want to create and contribute, sometimes to a fault, and sometimes at the expense of ignoring what already exists. Furthermore, understanding the current assets helps form the foundation and boundaries. Maybe the answer is to throw it all out and start over, but if the first action taken is to ignore what previously transpired, then, as goes the aphorism, get ready to repeat the same mistakes. Even though it's good to think outside the box, there still needs to be some semblance of a box to think outside of, and identifying the assets helps form that box. Most of these materials will exist scattered around: File shares and content management systems contain documents and drawings, HR and Identity Management systems contain people, existing project plans include upcoming schedules, etc.
These types of assets, including people, data and their entitlements, can be imported and modified in bulk, and in the case of files, maintain a foreign key to the source.
Organizations have requirements to articulate what activities they want done. When something is desired, it's written down in a variety of formats. Unfortunately, the business and customer use cases and requirements often times go missing or are usurped by technical requirements that mow-over what the business originally wanted. Let the requirements be captured early, and let them persist relative to the project plan. Similarly, large organizations draw on technical leaders to pen new designs while accommodating existing functionality. Let those blueprints hang, virtually, along side the requirements. These designs do not need to be complete (design up-front), but if the relationship is separated from the plan, or created as its own plan, then it's discrete from the implementation. Also, there are budgets of available time and money to consider, and the allocation of how much time and money may be spent within a window of time. Let those values be defined and referenced, whether they are visible or not, relative to any projects.
When the organizations methodology is formulated, and the requirements, use cases, and blueprints can be expressed against budgets and schedules, then a project plan can more easily be the representative tool it's supposed to be of what an organization wants to do, how long it will take, and how much it will cost. And, the relationship of the plan against the business drivers makes apparent what is wasteful in attempting to achieve a goal.
Organizations want or need work to be done in a particular way. Project and program managers define and execute project planning methodologies that correlate work activities against corporate and project requirements. While there are a number of project management methodologies, no one way accommodates every organization. For example, a waterfall project at Company A looks very different than a waterfall project at Company B, or an Agile Sprint at Company C smells nothing like an Agile Sprint at Company D. Because of myriad nuances affecting the process at each organization, and even between divisions and teams within that organization, it's important to be able to articulate the required methodology: What processes need to be followed, what are the time and cost constraints, and what are the goals and requirements common to every project following this process? At some point, a project plan may need to reconcile work performed across competing methodologies, and this is more readily accomplished when the methodologies are codified.
Organizations use project plans to introspect roadmaps, release schedules, allocate resources, and track work details. These plans exemplify the strategies and methodologies used to execute the project (I.E.: program management methodology), which steps are followed (I.E.: lifecycle phases), which artifacts are created, and how much is this whole thing going to cost, anyway? Functionally, lifecycles aggregate projects and related goals and budgets, and projects aggregate stages (aka phases) of work for a specific schedule. Projects accept models, requirements, dependencies, artifacts, and modules, and produce one or more modules or artifacts. Each project stage is a procedure of work according to the methodology, accepting or producing modules and artifacts. Work is a set of resources and tasks used to produce artifacts. Tasks, or the specific activities, represent one or more requirements that operate on other work, data, and/or notes to create artifacts.
Here's a fable for those familiar with Agile. A pig and a chicken are walking down the road. The chicken says, "Hey pig, let's open a restaurant." The pig says, "What would we call it?" The chicken says, "Ham'N'Eggs." The pig thinks for a bit and then says, "No thanks, I'd be committed but you'd only be involved."
Let's consider this fable for a moment. This fable is commonly used to describe the two types of project members on an agile team. A fable tells a short morality story. The moral of this story is the pig doesn't want to do it. Why is that? First, organizations and businesses, in almost every case, are not democracies. They are most likely an oligarchy. Efforts to foster communication and collaboration tend to be a passive-aggressive delegation of responsibility. In the Agile/fable sense, the chicken delegates the responsibility to the pig, and, at least by my observation, unaccountable for the outcome. Iterative development using scrum and TDD can be employed to great success, and it fosters collaboration and team-building. But even then, at its best, it leaves the chickens unaccountable for their influences, and those influences contributed to waste.
In an Agile environment, with chickens and pigs (who, according to the fable, don't want to be there), the resentment can be tangible. The overt or passive-aggressive response seems to be akin to the pig waiting for the chicken to turn its back and saying, "And, we'll serve Hot Wings."
In other words, it's important to acknowledge the power structure in which the planning takes place, because that heavily influences how certain activities should take place. Ultimately, this affects how teams collaborate, and what types of communities can form within these environments. The following is an idyllic project planning exercise: Show up, have all the requirements and resources available in an easy-to-consume format, have the preferred methodology and all of the stakeholders' various nuances in place, and then fill in the blanks to turn those requirements into a finished work product. The team collaborates to define functional requirements and test cases, and then is able to get right to work. Somehow, though, far too much time gets spent mincing through requirements in one document, and let's not forget the requirements in these other two documents, and let's just table these other requirements to get the detailed planning done, and, don't forget, let's have a meeting about everything and a follow-up meeting on that meeting. Most people acknowledge these shortcomings of the planning process, and the solutions lean towards fostering better intra-team and democratized communication, which is a circular, if not impotent, distraction from solving the real issue: Stop wasting time and resources.
The Rocket Community is the entitled access to some or all assets, some or all business elements, the program management process, and the capability to quickly integrate these together to create a plan. This isn't a tool to solve a people problem; It's a tool to help clarify where the constraints are happening.
I tried applying some common sense and a few management paradigms to program management in an effort to correct what I thought of as wasteful behaviors. Rocket was the result. Up next, we'll take a closer look at some of the features.
While working with CrossIdeas, which is a fine product in and of itself, I spied a gap between the governance separation-of-duty (SoD) declarations and policy enforcement points, such as in Business Rules Management Systems (e.g.: ESBs or rules engines). If governance software, be it CrossIdeas or SailPoint or Aveksa, do a somewhat decent job abstracting technical constructs into something the business can understand for purposes of auditing and reporting, could those same constructs also be given back to an authorization end point?
I realized I had a solution for this with the Account Manager 5 Authorization Service.
Here is an example: Bob has fourteen accounts, and access to numerous shares each with thousands of unmanaged or undiscovered files. Is it permissible for Bob to invoke a particular service while having a toxic combination of entitlements? Maybe, maybe not. It depends on the situation.
The typical SoD configuration may compare entitlements as expressions of business activity and report violations forthwith. While there may be some argument as for why someone should be allowed to be in violation, those toxic entitlement combinations may need to be banned from actual use. It may be ok for an account's LDAP account to have write permission to one database and read access to a business database on another system. Even if those two are considered risks, they may be permissible given a particular business need. However, there may also be a particular application or service that must block access regardless of the rationale. If the SoD policies and activities can interoperate with the BRMS system, then it's possible to address this situation. I acknowledge certain systems do this already, though usually within their own ecosystem and not necessarily with full awareness of all entitlements across the enterprise.
Here is another example: Bob is compliant per SoD policy and is actively using Application Charlie. Likewise, Carly is compliant and is actively using Application Delta. Meanwhile, Ernie plans to engage in some shenanigans by compromising Bob's and Carly's accounts. Ernie submit's one activity via Bob's account that requires approval, and then a corresponding activity via Carly's account to approve the just-submitted activity. Both users are authorized to perform the activities, and both the SoD configuration and BMRS systems recognize the successful authorized activities. But Ernie introduces an added dimension: Either these activities are both conducted on the same session, or from the same location, or at unexpected business hours - all of which fall into the realm of risk-based-access.
If SoD and RBA policies, and a BRMS can interoperate, and one of those stores an audit trail of authorization evaluations alongside contextual attributes, then that history can be used to mitigate some or most of the risk.
Intrigued by how this might be solved, I added a Separation of Duty rule type to the Account Manager 5 rules system. Then, I created a database view that translated the group entitlements cache with the URN values, primarily to break the reliance on the unique database identifiers and make the dataset more portable. I created a simplified business activity concept by reusing the DirectoryGroupType objects, to which entitlements and roles may be attached. This provides a straightforward way to read and cache permissions by business activity, and then find people or accounts that currently have those activities assigned. By pairing two or more of these patterns together as SEPARATION OF DUTY patterns, and setting the rule to DENY, that rule can be used for pure SoD reporting purposes, or be partnered with Risk- and Role-based authorization assertions. From an application point of view, it can still make a simple policy invocation, such as: Does Policy #1 Permit Person A? The only needed input parameter is the name of the Policy and the Person, while the policy evaluation includes SoD, RBA, and RBAC statements.
The end result is that an SoD policy, written to be consumable by the business, can be used for immediately enforcement, even when a violation exists or is determined to be allowed.